add first feature metadata draft #372
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| # Feature Metadata | ||
|
|
||
| Users want to enable abstract features, which means the deployment needs to know how to translate a feature name to a set of changes (configuration files, services, etc). | ||
|
|
||
| The metadata is a Hash with the feature name as the key and the feature definition as the value. | ||
|
Member
Author
There was a problem hiding this comment. This file describes how the metadata looks like, but not where it's stored. #309 stores it as a Hash in a Python file, but it's probably best suited as a standalone YAML file?
Member
There was a problem hiding this comment. I agree -- a yaml file will be easier.
Member
There was a problem hiding this comment. I agree that it needs to be a file. Do you think we need a single file per the whole foreman, or does it make more sense to have one per feature/plugin?
Member
Author
There was a problem hiding this comment. what would the benefit be if we have file-per-plugin? (I prefer single-file, unless there is a good reason not to)
Member
There was a problem hiding this comment. Each plugin will own its metadata - it is easier to manage it in the plugin repo, than to know that a specific obscure file needs to be changed.
Member
There was a problem hiding this comment. What if there are features that do not map to a plugin? Where would that metadata live?
Member
Author
There was a problem hiding this comment. right now it'd be a feature that has both
Member
Author
There was a problem hiding this comment.
How would the file from the repo come to Ansible? |
||
| The feature definition itself is again a Hash with the various properties of the feature. | ||
|
|
||
| ```yaml | ||
| feature_one: | ||
| property1: value_of_property1 | ||
| property2: value_of_property2 | ||
| … | ||
| feature_two: | ||
| property1: another_value_of_property1 | ||
| property2: another_value_of_property2 | ||
| … | ||
| … | ||
| ``` | ||
|
|
||
| The following properties are defined: | ||
evgeni marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * `description` (_String_): A human-readable description of the feature, can be used in documentation/help output. | ||
| * `internal` (_Boolean_): Whether the feature is user visible (shows up in documentation/help) or internal (just to perform additional configuration without user interaction). | ||
| * `foreman` (_String_): The name of the Foreman plugin to be enabled (via `FOREMAN_ENABLED_PLUGINS`). | ||
|
Member
There was a problem hiding this comment. Can I suggest a bit different approach here:
Member
Author
There was a problem hiding this comment. So the smart proxy deployment would need to read a file from the foreman role? That seems odd to me. There is also nothing to install, we're in a container here. We can either configure it, or leave it alone.
Member
Author
There was a problem hiding this comment. but that's also not really important right now, the metadata can be defined w/o the actual code being implemented and should have no influence on that |
||
| If `roles/foreman/tasks/feature/{{ foreman_plugin }}.yaml` exists, it will be executed to perform any plugin-specific setup. | ||
| * **FIXME**: task file not implemented yet | ||
| * `foreman_proxy` (_String_): The name of the Foreman Proxy plugin to be enabled (by deploying `roles/foreman_proxy/templates/settings.d/{{ foreman_proxy_plugin }}.yml.j2` to `/etc/foreman-proxy/settings.d`). | ||
| If `roles/foreman/tasks/feature/{{ foreman_proxy_plugin }}.yaml` exists, it will be executed to perform any plugin-specific setup. | ||
| * `hammer` (_String_): The name of the Hammer plugin to be enabled. | ||
| * **FIXME**: Not implemented, right now we use the same list as Foreman plugins, but needs modification for foreman-tasks and friends | ||
| * `role` (_String_): The name of the Ansible role that should be executed if this feature is enabled. | ||
| * `dependencies` (_Array_ of _String_): List of features that are automatically enabled when the user requests this feature. Usually will point at features with `internal: true`. | ||
| * `requirements` (_Array_ of _String_): List of features that are required but can't be automatically enabled (possible reasons: requires manual configuration, can't be enabled after initial deployment). | ||
|
Member
There was a problem hiding this comment. I see the question "can the feature be installed automatically" as an internal one, so the developer of a dependent feature should not be aware of this detail. I would like to consolidate the As an enhancement, we may consider adding feature-specific variables for each dependency. For example we may say "I am dependent on the Content feature, but only with Pulp3 as the backend" (assuming that
Member
Author
There was a problem hiding this comment. I agree it would be nice no to expose that distinction, but I don't see a good way to implement those "am I ready" checks. On the other hand, I think "katello" is the only "weird" feature that we declare as "can't be auto-enabled", and maybe we should ignore that detail for now? |
||
| Produces an error when the requirement is not met. | ||
|
|
||
| Properties can be omitted. | ||
|
|
||
| ## Examples | ||
|
|
||
| ### REX + Dynflow | ||
|
|
||
| ```yaml | ||
| dynflow: | ||
| internal: true | ||
| foreman_proxy: dynflow | ||
|
|
||
| remote_execution: | ||
| description: Foreman Remote Execution support | ||
| foreman: foreman_remote_execution | ||
| foreman_proxy: remote_execution_ssh | ||
| dependencies: | ||
| - dynflow | ||
| ``` | ||
|
|
||
| The `remote_execution` feature will enable the `foreman_remote_execution` plugin for Foreman and the `remote_execution_ssh` and `dynflow` plugins for Foreman Proxy. | ||
| The `dynflow` feature is hidden from the user and only present so that `remote_execution` can pull it in. | ||
|
|
||
| ### RH Cloud + Katello | ||
| ```yaml | ||
| katello: | ||
| description: Katello | ||
| foreman: katello | ||
|
|
||
| rh_cloud: | ||
| description: Foreman RH Cloud | ||
| foreman: foreman_rh_cloud | ||
| requirements: | ||
| - katello | ||
| ``` | ||
|
|
||
| The `rh_cloud` feature can't be enabled unless the `katello` feature is also present in the deployment. | ||
|
|
||
| ### Katello + tasks | ||
| ```yaml | ||
| foreman-tasks: | ||
| foreman: foreman-tasks | ||
| hammer: foreman_tasks | ||
|
|
||
| katello: | ||
| description: Katello | ||
| foreman: katello | ||
| dependencies: | ||
| - foreman-tasks | ||
| ``` | ||
|
|
||
| The `foreman-tasks` feature is automatically enabled when the user requests Katello, thus also gaining the Hammer integration for tasks which would be missing if we'd only let the Ruby gem dependency pull in `foreman-tasks`. | ||
|
Member
There was a problem hiding this comment. To see if I understand everything correctly, if I combine the last two examples, what we would have is:
Member
Author
There was a problem hiding this comment. Yeah. That would be the fuller example, I rather skipped multiple levels not to become too verbose (unless you think that's helpful?)
Member
There was a problem hiding this comment. I needed to see this bigger, combined example to make sure I understood it will be one big hash with everything rather than a bunch of small hashes. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What makes a feature abstract?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to me mostly the fact that the implementation can be in foreman, in the proxy, in some sidecar (iop) or something unknown yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would define a
featureas a set of configuration steps. The configuration step could be "install gem", "install smart-proxy plugin", "install a container" or "modify a config file". I wonder if we can reuse Ansible native constructs (maybe a module) for such grouping instead of defining another grouping mechanism.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in reality, no "install" actions will happen tho, as we're working with pre-built containers.
possible actions (with todays architecture):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now that you mention that, it means that there is no such thing as smart-proxy machine anymore. It's just a container installed somewhere, and you have two actions to do: deploy the container on a desired machine and register a new smart proxy record in the Foreman database.
So we will need to orchestrate the container deploy on one machine and registering it on another.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is where this is headed but we are still bound by the concepts of a foreman-proxy and one per machine (also think Capsules).