Blueprint: https://blueprints.launchpad.net/fuel/+spec/release-as-a-plugin
As a deployment Engineer I want to express a Fuel Release as a Fuel Plugin so that I could define, maintain and deploy various flavors of customized OpenStack deployments in a clean isolated way, externalized from common Fuel provisioning layer.
The nailgun repo still holds onto one of the remaining parts of the data model the release fixture. This fixture is used to describe everything about the deployment from the ground up and is where every change can possibly be expressed.
By moving the release fixtures openstack.yaml completely into the plugin framework we’re opening road to following changes:
Support of the case when there are no release is required.
Basic releases will be shipped as pre-installed plugins. It becomes possible to uninstall them completely leaving Fuel without releases at all.
UI should support case when no releases installed, not allowing to pass in cluster creation wizard further that a release selection or not allow to start this wizard at all.
Message about what to do if no releases are installed should be displayed to user.
Providing releases as a plugin supposes that Fuel bundled release fixture should be shipped and pre-installed as plugin package.
For the details, please, see [1] spec.
Data model of Nailgun will be left intact except the changes in incoming release configuration.
Release name version is determined in metadata with following fields:
releases:
- release_name: 'ExampleRelease' #required
description: 'Example Release Description' #required
operating_system: 'ubuntu' #required, or its alias "os"
version: '0.0.1' #required
No changes in REST API
Plugins installation is not changed.
Fuel plugin adapter should now be able to understand new format of release: records declared in plugin metadata.yaml.
New release loader should be integrated with plugin adapters.
If is_release is defined and set to true for record in the releases: section this is a hallmark of release definition.
If is_release is defined and set to true the release_name is required.
is_hotpluggable flag is not available for the release plugins and will be ignored.
Release could contain any data matching FPB and Fuel validation schema, without any restriction related to the OS version or bundling something other than OS into the release plugin.
To make updates/upgrades simpler, it’s supposed that plugin could contain either releases or releases extensions, but not both of them at the same time. FPB validator should provide warning if more than one release is defined or plugin name is different from the release name.
As the result plugin developer is free to define any folders and files structure that is comfortable to work with.
Example of metadata.yaml:
...
name: 'ExampleRelease'
version: '10.0.0'
package_version: '5.0.0' # plugin package version
releases:
- release_name: 'ExampleRelease'
description: 'Example Release Description' #required
operating_system: 'ubuntu' #required, or its alias "os"
version: 'mitaka-10.0' #required
# is_release should be true for plugins that define releases
is_release: true
# base_release_path allows defining template from which all data tree
# will be inherited by overriding keys.
base_release_path: ubuntu-10.0.0/_base.yaml
networks_path: ubuntu-10.0.0/metadata/networks.yaml
volumes_path: ubuntu-10.0.0/metadata/volumes.yaml
roles_path: ubuntu-10.0.0/metadata/roles.yaml
network_roles_path: ubuntu-10.0.0/metadata/network_roles.yaml
components_path: ubuntu-10.0.0/metadata/components.yaml
attributes_path: ubuntu-10.0.0/attributes/attributes.yaml
vmware_attributes_path: ubuntu-10.0.0/attributes/vmware.yaml
node_attributes_path: ubuntu-10.0.0/attributes/node.yaml
nic_attributes_path: ubuntu-10.0.0/attributes/nic.yaml
bond_attributes_path: ubuntu-10.0.0/attributes/bond.yaml
graphs:
- type: default
tasks_path: ubuntu-10.0.0/graphs/deployment_graph.yaml
- type: provisioning
tasks_path: ubuntu-10.0.0/graphs/provisioning_graph.yaml
- type: deletion
tasks_path: ubuntu-10.0.0/graphs/deletion_graph.yaml
- type: network_verification
tasks_path: ubuntu-10.0.0/graphs/network_verification_graph.yaml
deployment_scripts_path: ubuntu-10.0.0/deployment_scripts/
repository_path: ubuntu-10.0.0/repositories
Attributes except deployment scripts, repository path and graph will be ignored for old-fashioned plugin release (extending existing release functionality)
Graphs types are highly required in the release description for providing good UX experience to plugins developers and deployment engineers for the Deploy changes action. Graph concept extension.
Should be able to check new release schema and files are linked as files and folders paths.
Also it should provide appropriate warnings in case of deprecated syntax signs.
Plugins Package v5.0.0 will be supported starting from Fuel v9.1.0. Appropriate validation should be defined.
Under the hood FPB will perform three operations:
Data files discovery and loading making data tree from plugin files and rendered configuration templates. During processing of metadata file all attributes with _path suffix will be considered as special one and processed using the following conditions:
if some_key_path key is pointing to file or file-like object and it is possible to load data from it (YAML/JSON) key will be replaced to version without suffix some_key and data will be placed under this key in data tree.
if key with the _path suffix is pointing to folder like ./release/fuel-10.0/, it will be left intact.
if key with a path suffix _path is a glob expression like release/graphs/\*.yaml file search will be run.
All found files matching glob will be merged into one list if they all have list root or their properties will be merged into dict if their root is dict. In the case of mixed root loader will fail.
After data is merged as well as data from single file it will be placed under the key without _path suffix and original key will be removed from data tree.
Data tree validation.
Plugin building and packaging (identical to the current functionality)
modes release parameter is deprecated and will be removed in further versions.
tasks.yaml no further supported.
fuel_version field currently is not processed by any business logic in nailgun and should be deprecated.
In perspective current Fuel Library should become a plugin.
There is alternative implementation offered by bgaifullin@mirantis.com
Release are provided as separate package and it is not related to the plugin.
Each release can be registered in nailgun by using API.
That means it is not required to update plugins model, only need to move openstack.yaml to the fuel-library side.
The release package should include openstack.yaml and deployment tasks.
The plugins model will be kept as is and plugins only extend releases which are registered in nailgun instead of new release declaration.
On the other hand release and plugin have quite similar data structures that are different in the ways they are managed by business logic and how they are delivered.
It seems sane to make their delivery and management as close as it’s possible as well.
It will be possible to ship release upgrades as a plugin.
None
Fuel Plugin Builder validator should be able to validate new releases parameter structure.
None
None
None
This feature highly affects Fuel plugins and library developers.
None
Add documentation about fuel plugins format.
Other contributors:
None
[1] - https://blueprints.launchpad.net/fuel/+spec/release-description-in-fuel -library