https://blueprints.launchpad.net/fuel/+spec/cinder-neutron-plugins-in-fuel
Cloud operators want to extend and change behavior of Fuel in order to do that, Fuel should provide plugin mechanism.
Sometimes Fuel user wants to extend Fuel to install Cinder/Neutron plugin. Right now user changes the code of Fuel services rebuilds and adds repositories manually.
The current approach causes a lot of problems:
For the current release we have the next constraints:
Plugin developer will be able to develop plugin on his machine, we will specify all requirements for environment, like version of OS and additional dependencies.
Note, fpb should provide –debug key to turn on debug information.
fpb should perform checks during the plugin build
From user point of view:
Install script workflow:
This structure should be generated by fpb script.
.
|-- deployment_scripts
| `-- deploy.sh
|-- environment_config.yaml
|-- LICENSE
|-- metadata.yaml
|-- pre_build_hook
|-- README.md
|-- repositories
| |-- centos
| | `-- .gitkeep
| `-- ubuntu
| `-- .gitkeep
`-- tasks.yaml
Here is detailed description of some of the files:
metadata.yaml file
# Plugin name
name: fuel_awesome_plugin
# Human-readable name for your plugin
title: Awesome plugin
# Plugin version
version: 1.0.0
# Description
description: Enable to use plugin X for Neutron
# Required fuel version
fuel_version: ['6.0']
# The plugin is compatible with releases in the list
releases:
- os: ubuntu
version: 2014.2-6.0
# User can specify if his plugin is ha compatible or not
mode: ['ha', 'multinode']
deployment_scripts_path: deployment_scripts/
repository_path: repositories/ubuntu
- os: centos
version: 2014.2-6.0
mode: ['ha', 'multinode']
deployment_scripts_path: deployment_scripts/
repository_path: repositories/centos
# If plugin can work with several openstack releases
# user can define different directories with packages
# and deployment scripts, at the same time he can specify
# the same directory for all of the versions, it depends
# on plugin implementation
- os: centos
version: 2014.2-7.0
mode: ['multinode']
deployment_scripts_path: 7.0/deployment_scripts/
repository_path: 7.0/repositories/centos
# Version of package format
package_version: '1.0.0'
environment_config.yaml
attributes:
fuel_simple_port:
value: 2333
label: 'Port'
description: 'Port which be used for service binding'
weight: 25
type: "text"
fuel_simple_host:
value: 0.0.0.0
label: 'Host'
description: 'Host which be used for service binding'
weight: 10
type: "text"
tasks format description
# Roles which the task should be applied on
- role: ['controller', 'cinder']
stage: pre_deployment
type: shell
parameters:
cmd: configure_glusterfs.sh
timeout: 42
# Task is applied for all roles
- role: "*"
stage: post_deployment
type: puppet
parameters:
puppet_manifest: cinder_glusterfs.pp
puppet_modules: modules
timeout: 42
Directory /var/www/plugins which contains all of the plugins, should be mounted to the next containers.
User wants to be able to upgrade his plugin, if there will be some new plugin with updated version of package or other bug fixes. For the current version we don’t provide any upgrade mechanism for plugins. In theory we could use this mechanism if openstack patching feature was not experimental.
There are a lot of alternatives, the best of them are described in Future improvements section and will be implemented later.
Separate services which keeps information about all of the plugins in the system, it should know how to install or delete plugins. We will use this service instead of install script to install the plugins.
Nailgun drivers and hooks which will provide a way to change deployment/provisioning data for orchestrator. Also it will be possible to add new role.
Add new step in wizard, add new tab, for cluster env, add new settings window for node configuration.
User will be able to install any service on the master node, the good example of such kind of plugins is OSTF.
General use cases:
More specific use cases:
There will be new model in nailgun, Plugins with many to many relation to Cluster model. Model for many to many relation ClustersPlugins will be used in order to disable or enable plugin for specific environment.
Plugins
ClustersPlugins
GET /api/v1/plugins/
Returns the list of plugins
[
{
"id": 1,
"name": "plugin_name",
"version": "1.0",
"description": "Enable to add X plugin to Neutron",
"title": "Plugin name",
"fuel_version": ["6.0"],
"package_version": "1",
"releases": [
{
"os": "ubuntu",
"version": "2014.2-6.0"
},
{
"os": "centos",
"version": "2014.2-6.0"
}
]
}
]
POST /api/v1/plugins/
{
"id": 1,
"name": "plugin_name",
"version": "1.0",
"description": "Enable to add X plugin to Neutron",
"title": "Plugin name",
"fuel_version": ["6.0"],
"package_version": "1",
"releases": [
{
"os": "ubuntu",
"version": "2014.2-6.0"
},
{
"os": "centos",
"version": "2014.2-6.0"
}
]
}
GET /api/v1/plugins/1/
Get the information about specific plugin, where 1 is id of the plugin
{
"id": 1,
"name": "plugin_name",
"version": "1.0",
"description": "Enable to add X plugin to Neutron",
"title": "Plugin name",
"fuel_version": ["6.0"],
"package_version": "1",
"releases": [
{
"os": "ubuntu",
"version": "2014.2-6.0"
},
{
"os": "centos",
"version": "2014.2-6.0"
}
]
}
PATCH /api/v1/plugins/1/
Update specified attributes for plugin
Accepts the same format as response from GET request.
PUT /api/v1/plugins/1/
Update all of the attributes
Accepts the same format as response from GET request.
DELETE /api/v1/plugins/1/
Remove a plugin from DB, should have validation which returns the error, if plugin is used by some environment.
Validation should be disabled if plugin deletion is performed with force parameter in url. It will be required for development.
As it was described above, user specifies the structure like this
- role: ['controller', 'cinder']
stage: pre_deployment
type: shell
parameters:
cmd: configure_glusterfs.sh
timeout: 42
- role: *
stage: post_deployment
type: puppet
parameters:
puppet_manifest: cinder_glusterfs.pp
puppet_modules: modules
timeout: 42
Then nailgun configures this data in the next format
# This stages should be run after astute yaml for role
# and repositories are on the slaves
pre_deployment:
# Add new repo
- # This task will be autogenerated by nailgun
type: upload_file
uids: [1, 2, 3]
priority: 0
parameters:
path: /etc/apt/sources.list.d/plugin_name-1.0
data: the file data
# Overwrite already existed file?
overwrite: true
# Create intermediate directories as required
parents: true
# File permission
permissions: '0644'
# User owner
user_owner: 'root'
# Group owner
group_owner: 'root'
# What permissions should be set for folder
dir_permissions: '0644'
- # This task will be autogenerated by nailgun
type: sync
uids: [1, 2, 3]
priority: 1
parameters:
src: rsync:///var/www/nailgun/plugins/plugin_name-1.0/scripts
dst: /etc/fuel/plugins/plugin_name-1.0/scripts
- type: shell
uids: [1, 2, 3]
priority: 10
parameters:
cmd: configure_glusterfs.sh
timeout: 42
# This parameter should be autogenerated by nailgun
cwd: /etc/fuel/plugins/plugin_name-1.0
post_deployment:
- type: puppet
uids: [1, 2, 3, 4, 5, 6]
priority: 20
parameters:
puppet_manifest: cinder_glusterfs.pp
puppet_modules: modules
timeout: 42
# This parameter should be autogenerated by nailgun
cwd: /etc/fuel/plugins/plugin_name-1.0
deployment_info:
# Here is deployment information in the same format
# as it is now
In the first release orchestrator should fail deployment if one of the tasks is not executed successfully.
Plugin developer can use any bash scripts or puppet manifests in order to perform plugin installation, here is a list of requirements for the scripts
Nailgun should provide ability to mix new environment attributes which are required for plugin configuration
Also nailgun should extend default deployment/patching tasks with tasks for pre and post deployment hooks, where should be specified paths to scripts directory on the master node
For each plugin nailgun generates separate section with checkbox to show it on UI.
It is not required to add new logic on UI tab, nailgun generates checkbox for each plugin on settings tab, so user can enable or disable particular plugin and configure it.
Because we don’t have any python code in our plugins, plugin will depend on openstack release, we don’t delete releases, as result it’s not necessary to check if plugin is compatible with the current version of fuel. Also plugin is stored on shared volume which we mount to nailgun container.
When we get plugins with python code, in upgrade script we will have to check if plugins are compatible with the new version of fuel, if they aren’t compatible, upgrade script should show the message with the list of incompatible plugins and it should fail the upgrade. If user wants to perform upgrade, he should provide the directory with new plugins, which will be updated during the upgrade, or user should delete plugins which he doesn’t use.
This feature has a huge security impact because the user will be able to execute any command on slave nodes. Security is included in acceptance criteria of plugins certification, see Plugins certification section.
Installation script will create notification after plugin is installed.
User should be able to disable or enable plugin for specific environment.
Deployment
Nailgun
Also performance is added as acceptance criteria for core plugins, see Plugins certification section.
Plugin developer will be able to execute pre/post deployment hooks for the environment.
Changes which are required in astute:
The topic isn’t covered by this document, separate document needs to be created.
Items which should be reviewed during plugin certification:
After plugin is certified user should be able to add plugin in our plugins repository.
User should not follow fuel’s workflow in development, as result they can have their own repositories with code
We should provide repository with built plugins where user will be able to download plugin.
Core plugin is a plugin which is developed and supported by fuel team. They can or cannot be included in an iso. Build system should has config with a list of built-in plugins.
Features design impacts:
Development impacts:
Primary assignee:
Other contributors:
There will be several core plugins, which QA team will be able to install and test.
For neutron it will be LBaaS plugin, for Cinder it will be GlusterFS backend.
Also it will be required to have infrastructure, where plugin developer will be able to test his plugins. He should have ability to specify plugin url and the set of plugins, which he would like to run tests with.
Also we can have core plugins, which should be included in our testing cycle, it means that we should run system tests with plugins, and also run plugins specific tests.