Update to new formula standards #4
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
7a75790 to
d9061fb
Compare
|
I ran the
|
|
One thing I'm wondering is what is the best for configuration: Like actually, the configuration are directly under the component, for example values:
master:
enabled: true
auth_code: someverystrongsecret
chunkserver:
enabled: true
auth_code: someverystrongsecret
master_host: foo.example.net
hdds:
/srv/moosefs-storage: {}Or under a values:
master:
enabled: true
config:
auth_code: someverystrongsecret
chunkserver:
enabled: true
config:
auth_code: someverystrongsecret
master_host: foo.example.net
hdds:
/srv/moosefs-storage: {}This will require only a little modification of |
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
d9061fb to
8db2aed
Compare
My personal preference tends to be having a |
I completely agree with you, I'll wait for one or two more review of this before making the change. Thanks. |
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
8db2aed to
444907c
Compare
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
4 times, most recently
from
02e6305 to
70bd1bf
Compare
|
I fixed some issue in
|
This is the base files for standard community formulas. Reset the `pillar.example` for new values
Force hostname that will be used in generated configuration files.
The v5 `map.jinja` is a generic and configurable system to load
configuration values, exposed as the `mapdata` variable, from
different places:
- YAML files and templates from the fileserver for non-secret data
- pillars or SDB are preferred for secret data
- grains or `config.get`
The `map.jinja` optional sources are configured with compound targeting like
syntax `[<TYPE>[:<OPTION>[:<DELIMITER>]]@]<KEY>` with the following
default ordered sources:
- `Y:G@osarch`: YAML file and Jinja template named after `osarch` grain
- `Y:G@os_family`: YAML file and Jinja template named after `os_family` grain
- `Y:G@os` YAML file and Jinja template named after `os` grain
- `Y:G@osfinger` YAML file and Jinja template named after `osfinger` grain
- `C@{{ tplroot ~ ':lookup' }}`: dict retrieved with `salt["config.get"]`
- `C@{{ tplroot }}`: dict retrieved with `salt["config.get"]`
- `Y:G@id`: YAML file and Jinja template named after `osarch` grain
This is done by two new libraries:
- `libs/libmatchers.jinja` provides the `parse_matchers` macro to
parse strings looking like compound matchers, for example `Y:G@osarch`
- `libs/libmapstack.jinja` provides the `mapstack` macro to load
configuration from different sources described by matchers
Post-processing of `mapdata` variable can be done in a
`parameters/post-map.jinja`.
The v5 `map.jinja` is documented in `docs/map.jinja.rst`.
BREAKING CHANGE: `map.jinja` now exports a generic `mapdata` variable
BREAKING CHANGE: The per grain parameter values are now under
`moosefs/parameters/`
The `files_switch` macros returns a `source` parameter for `file.managed` state to lookup the source in configurable places. See `docs/TOFS_pattern.rst` for the Template Override and Files Switch (TOFS) pattern.
* moosefs/libs/libconfig.jinja (boolean): convert a jinja boolean to configuration file boolean. (set_config): set a configuration parameter or commented default value. (format_export): format an export entry.
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
70bd1bf to
5a93c69
Compare
|
I rebase my branch and switch to the I found it cleaner to have One thing that should be great is the possibility to test by writing data in the mount point but I don't know what could be a best practice to do that:
If someone has an idea 🙏 |
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
5a93c69 to
3d11998
Compare
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
2 times, most recently
from
59b74b4 to
2903a14
Compare
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
2 times, most recently
from
97190a0 to
d3cdbcc
Compare
The `moosefs.master` is split into subcomponents: - `moosefs.master.package` to handle packages installation / removal - `moosefs.master.config` to handle service configuration files - `moosefs.master.service` to handle start and stop of the service BREAKING CHANGE: `moosefs.master` is split in `moosefs.master.package`, `moosefs.master.config` and `moosefs.master.service`
The `moosefs.metalogger` is split into subcomponents: - `moosefs.metalogger.package` to handle packages installation / removal - `moosefs.metalogger.config` to handle service configuration files - `moosefs.metalogger.service` to handle start and stop of the service BREAKING CHANGE: `moosefs.metalogger` is split in `moosefs.metalogger.package`, `moosefs.metalogger.config` and `moosefs.metalogger.service`
The `moosefs.chunkserver` is split into subcomponents: - `moosefs.chunkserver.package` to handle packages installation / removal - `moosefs.chunkserver.config` to handle service configuration files - `moosefs.chunkserver.service` to handle start and stop of the service BREAKING CHANGE: `moosefs.chunkserver` is split in `moosefs.chunkserver.package`, `moosefs.chunkserver.config` and `moosefs.chunkserver.service`
The `moosefs.client` is split into subcomponents: - `moosefs.client.package` to handle packages installation / removal - `moosefs.client.config` to configure the mount BREAKING CHANGE: `moosefs.client` is split in `moosefs.client.package` and `moosefs.client.config`
The `moosefs.cgi` install only the `cgi` application.
The `cgiserv` is split into subcomponents: - `moosefs.cgiserv.package` to handle packages installation / removal - `moosefs.cgiserv.config` to handle service configuration files - `moosefs.cgiserv.service` to handle start and stop of the service BREAKING CHANGE: the `cgiserv` was provided by `moosefs.master` and is now split in `moosefs.cgiserv.package`, `moosefs.cgiserv.config` and `moosefs.cgiserv.service`
The `moosefs.cli` install only the `mfscli` command line tool.
The `moosefs.netdump` install only the `mfsnetdump` command line utility.
Minion should only have the proper configuration set and running `state.apply moosefs` will apply only enabled components. BREAKING CHANGE: you must set `master:enabled`, `metalogger:enabled`, `chunkserver:enabled`, `cgiserv:enabled`, `client:enabled`, `cli:enabled` and `netdump:enabled` to install each component with the top level state
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
d3cdbcc to
4983d3c
Compare
baby-gnu
force-pushed
the
feature/update-to-new-formula-standards
branch
from
4983d3c to
7971280
Compare
|
In my latest modification:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]Changes related to the build system[chore]Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]Changes to the continuous integration configuration[feat]A new feature[fix]A bug fix[perf]A code change that improves performance[refactor]A code change that neither fixes a bug nor adds a feature[revert]A change used to revert a previous commit[style]Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]Documentation changes[test]Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE?YES
map:map.jinjanow exports a genericmapdatavariablemap: The per grain parameter values are now undermoosefs/parameters/init: you must setmaster:enabled,metalogger:enabled,chunkserver:enabled,cgiserv:enabled,client:enabled,cli:enabledandnetdump:enabledto install each component with the top level statemaster:moosefs.masteris split inmoosefs.master.package,moosefs.master.configandmoosefs.master.servicemetalogger:moosefs.metaloggeris split inmoosefs.metalogger.package,moosefs.metalogger.configandmoosefs.metalogger.servicechunkserver:moosefs.chunkserveris split inmoosefs.chunkserver.package,moosefs.chunkserver.configandmoosefs.chunkserver.serviceclient:moosefs.clientis split inmoosefs.client.packageandmoosefs.client.configcgiserv: thecgiservwas provided bymoosefs.masterand is now split inmoosefs.cgiserv.package,moosefs.cgiserv.configandmoosefs.cgiserv.serviceRelated issues and/or pull requests
saltstack-formulas/template-formula#21
Describe the changes you're proposing
I update the formula to new community standards:
map.jinja.cleanedto remove themlibs/movePillar / config required to test the proposed changes
Debug log showing how the proposed changes work
./bin/kitchen converge default-debian-11-3004-1-py3Documentation checklist
README(e.g.Available states).pillar.example.Testing checklist
state_top).Additional context