How to make a fuel plugin (for example, NFS). Part 1

Authors: Alexander Kislitsky, Evgenia Schumacher, Vyacheslav Struk, Ilya Stechkin

So, you asked to talk about how to make plugins for Fuel . We are pleased to fulfill this request. But to talk about “spherical plug-in vacuum” is difficult and uninteresting. Therefore, we decided to take for example the NFS plugin and tell how it was created and tested.

To begin with, we recall that the OpenStack ecosystem is being developed by the efforts of individual engineers and engineering teams that offer solutions for specific tasks, expanding the boundaries of what is possible for the entire community. From this point of view, plug-ins are the most correct architectural solution for a project that exists within an ecosystem.
Fuel is one of those right projects. It is designed to facilitate the deployment of Mirantis OpenStack and the subsequent administration of the cloud. Everyone has the opportunity to extend the functionality of Fuel through plug-ins.
')
In this series of articles, we do not claim to be complete instructions - we cannot compete with the Fuel Plugin SDK in terms of the format of the material. But this text has several significant advantages. First, it is in Russian. Secondly, it describes in detail the history of the creation of a specific plug-in, that is, you have the opportunity, along with the developer, Alexander Kislitsky, to go all the way from beginning to end. And finally, thirdly, if something turns out to be unclear, you can always ask us questions in the comments and we will try to give comprehensive answers. So, good hunting!

There are a few drawbacks. The main problem is that this series of articles is based on the experience of creating a plug-in for Fuel version 6.0. And the current version is now 6.1. However, 6.1 will soon become obsolete, it will be replaced by 7.0. In other words, the Fuel Pluggable framework is a living organism that grows and improves, and which has certain limitations. They change from version to version. So at that moment, when you read this text, it is already slightly out of date. But the links given in the article will allow readers to update the materials themselves.

What are plugins for Fuel?

In most cases, you will use plugins to extend the functionality of such OpenStack elements as:

1. Compute
2. Network
3. Storage
4. Operations (logging, monitoring, security)

Using plug-ins, you can create, for example, alternative backends for these components, or solve cloud monitoring tasks: LMA Collector is installed on nodes such as controller, compute and storage nodes. This module collects logs, metrics and notifications from various services of the OpenStack ecosystem and sends this information to external database backends like ElasticSearch and InfluxDB. Or Zabbix - plugin. This plugin installs Zabbix, one of the most popular solutions for enterprise level monitoring, created on the basis of open source. A complete list of current plugins can be found here . Please note that they work correctly for Fuel 6.1. Cloud monitoring is generally a trendy topic. And we will try to return to it in the following articles.

Please note: each plugin that you create should be stored in a separate repository. We recommend using StackForge for this purpose (this is a tool adopted among OpenStack developers. You can read more about it here - the text in English). It is very convenient to have everything you need at hand: the code, the specs, and the documentation ... Although there are no specs and docks in our test example , we still strongly recommend adding them. Here in the plugin for Calico everything is done as it should. Other developers will thank you because they will be able to use the Gerrit workflow for sequential integration (CI) code, update the plugin in accordance with the requirements of future releases of Mirantis OpenStack.

Plugin structure

The created plugin has the following form:

fuel_plugin_name /
Deployment── deployment_scripts
Deploy └─ deploy.sh
Environment── environment_config.yaml
Meta── metadata.yaml
Pre── pre_build_hook
Rep── repositories
│ ├── centos
│ └── ubuntu
Tasks── tasks.yaml

This template can be generated automatically using the Fuel plugin builder. Hands these files do not need to create.

YAML is a simple language for describing data. This format allows you to enter the following information:

- tasks.yaml - this variable describes when, where and how to run the script
- metadata.yaml - sets the name, version and links (see example metadata for fuel 6.1 here ) for your plugin
- environment_config.yaml - sets the parameters specific to this plug-in, which the user can set in the Settings tab of the Fuel interface
- deployment_scripts — directory where you can add your bash scripts or puppet manifests.
- repositories - allows you to add Ubuntu or CentOS packages necessary for the plug-in to work.

What kind of tasks does Fuel support?

Fuel supports the “shell” and “puppet” tasks, allows you to execute specific shell commands and Puppet manifests. Here is an example of a shell task:

# This task will be applied to controller nodes,
# here you can also specify
# ['cinder', 'compute'] will be applied only on
# cinder and compute nodes
- role: ['controller']
stage: post_deployment
type: shell
parameters:
cmd: ./deploy.sh
timeout: 42
# Task is applied for all roles
- role: '*'
stage: pre_deployment
type: shell
parameters:
cmd: echo all> /tmp/plugin.all
timeout: 42

In this example, the first task performs deploy.sh script.
./deploy.sh will be executed after deployment as stated in the corresponding description.
The second task creates /tmp/plugin.all file, with the text 'all', that is, it runs the "echo all> /tmp/plugin.all" command.

Execution of tasks using Puppet allows you to apply your own Puppet manifests to OpenStack nodes, such as:

1. Add the site.pp file to the deployment_scripts / puppet / manifests / directory. puppet_manifest describes the path to the directory for the manifest related to deployment_scripts
2. Insert all required modules in the deployment_scripts / puppet / modules directory - puppet_modules define the path to the directory for modules related to ** deployment_scripts

Example:

# Deployment will be applied on controllers only
- role: ['controller']
stage: post_deployment
type: puppet
parameters:
puppet_manifest: puppet / manifests / site.pp
puppet_modules: puppet / modules
timeout: 360

Fuel does not use Puppet Master. Instead, the Fuel task executor copies the manifest from the Fuel Master node and runs the 'puppet apply' command on each selected node. We recommend using Puppet tasks in your plugins instead of running Puppet in shell tasks. Those who are interested in the internal architecture of Fuel, we send to read Fuel development documentation , since this information is beyond the scope of this topic.

The type of plugin being created is not critical - it does not affect the development process, it will not change. After installing the Fuel elements of the plugin will be displayed in the Settings tab (Settings).
Unfortunately, the current version of Fuel does not guarantee the display of full information about the plugin. Now information about plugins is not displayed in the Fuel Wizard, but is displayed in the Fuel Settings, so it is not very convenient to work from the point of view of the UX. We know about it and are working to make the process more comfortable. Now, if there are not enough tools, you can use the CLI, which is also not very user friendly, but for admins who use Fuel, that’s necessary.
Once again we recall that all the details regarding the formatting of tasks you can get in the Fuel Plugin SDK . And we move from general questions directly to the procedure for creating a plugin.

To be continued…