Partners and the Mirantis Unlocked validation program -- Part 2: Fuel Plugins
According to the latest OpenStack user survey, Fuel is extremely popular as a deployment tool, and we believe one of the reasons for that is Fuel plugins.
The plugin framework became a part of the Fuel architecture in the 6.1 release because the Fuel development team realized external contributors need an easy way to extend Fuel functionality without building on the actual core. To make this possible, they revised the Fuel architecture.
This means if you are a vendor who wants to add functionality to deployments of OpenStack (or even just to Fuel), you can choose to contribute to the Fuel project directly, or you can create a plugin. The latter is much easier because there’s no need to go through multiple cycles of approving blueprints, and so on. To begin, you create a repository for your Fuel plugin (for example, https://github.com/openstack/fuel-plugin-mellanox) and create a Launchpad project (for example, https://launchpad.net/lma-toolchain). You should still follow OpenStack community standards, but you are the owner of your own project.
Right now there are more than 30 Fuel plugins listed in DriverLog, and more than 60 repositories in the https://github.com/openstack space containing “fuel-plugin” in their names. (We believe there are many more Fuel plugins in the world, but we just don’t know about them.) You can imagine how these plugins make the Fuel user experience a much richer user experience.
Before we move on to talk about the details, let's make sure we're on the same page when it comes to a little terminology:
There is a business reason for validation, however. If you want to confirm that your plugin is compatible with a particular version of MOS and publish it to the Fuel plugin catalog on Mirantis’ site, you need to go through the validation process. The greatest benefit here is a high level of trust from Mirantis’ Solution Architects and from Mirantis’ customers.
You can read about what the Fuel plugin validation process includes, but let’s spend some time explaining how this process works and why.
During Fuel plugin validation, Mirantis acts as a core reviewer. The Fuel plugin SDK says, “Here are the rules for writing, testing, documenting and maintaining plugins.” If you don’t plan to validate your plugin with Mirantis, it’s up to you to follow or not follow those recommendations. But if you plan on taking advantage of validation, these recommendations become requirements you need to meet.
The Fuel plugin SDK provides different types of templates (for code, for documents, for CI, etc.), but designing, developing, testing and documenting every unique part of a plugin is a developer’s responsibility. Here's a look at the relative responsibilities of the Fuel plugin developer versus Mirantis:
Sometimes a client-based Mirantis project team faces a situation when a validated plugin does not fully meet customer requirements. It’s completely normal: most Mirantis customers have large installations, and some requirements can be quite exotic, while some plugins have only MVP functionality. In this case, it may be necessary to add features to the plugin, or even to write a new one. In this case, the Mirantis project/deployment team connects with the Fuel plugin’s maintenance team and decides how to proceed.
Fuel is open source (as part of OpenStack Big Tent), and developers are advised to keep plugin code open source, too, though packages can be proprietary. For example, the Juniper Contrail Fuel plugin is not open source. (The Fuel community also recommends publishing plugins in DriverLog to keep a record of existing plugins.)
So what happens if users want to deploy MOS with Juniper Contrail SDN as a Neutron backend? In this case, they need to download the Fuel plugin from the Mirantis Fuel Plugin Catalog and then buy the Juniper Contrail packages from Juniper. Juniper Contrail bits should be downloaded and stored in a repository from which the Fuel plugin will get them before deployment and configuration.
The demo serves several purposes:
There's also the matter of User Acceptance (Partner Acceptance) testing. In this case, the Mirantis validation team receives a Fuel plugin rpm package. Then, in either a Mirantis’ or a partner's lab, we install Fuel and the Fuel plugin, deploy an environment according to the steps described in the User Guide and perform actions according to the Test Plan.
Basically we are testing repeating the user's journey to make sure it is successful. If we see any inconsistencies or bugs, we ask partners to fix them.
All validated plugins (both an rpm and a set of documents) are published in the Mirantis Fuel plugin catalog.
Mirantis believes that our strength is in integration with partners, and our customers should rely on these integrations.
The Mirantis Validation team is always ready to help all plugin developers succeed. We are constantly contributing to the Fuel plugin SDK and answering questions in IRC chats (on Freenode at #fuel-dev), the OpenStack mailing list, and on the unlocked-tech@mirantis.com mailing list.
The plugin framework became a part of the Fuel architecture in the 6.1 release because the Fuel development team realized external contributors need an easy way to extend Fuel functionality without building on the actual core. To make this possible, they revised the Fuel architecture.
This means if you are a vendor who wants to add functionality to deployments of OpenStack (or even just to Fuel), you can choose to contribute to the Fuel project directly, or you can create a plugin. The latter is much easier because there’s no need to go through multiple cycles of approving blueprints, and so on. To begin, you create a repository for your Fuel plugin (for example, https://github.com/openstack/fuel-plugin-mellanox) and create a Launchpad project (for example, https://launchpad.net/lma-toolchain). You should still follow OpenStack community standards, but you are the owner of your own project.
Right now there are more than 30 Fuel plugins listed in DriverLog, and more than 60 repositories in the https://github.com/openstack space containing “fuel-plugin” in their names. (We believe there are many more Fuel plugins in the world, but we just don’t know about them.) You can imagine how these plugins make the Fuel user experience a much richer user experience.
Before we move on to talk about the details, let's make sure we're on the same page when it comes to a little terminology:
- Fuel plugin framework: An architecture term meaning that Fuel is designed to allow plugin development that extends its functionality.
- Fuel plugin SDK (Software Development Kit): A set of instruments, practices, documents and tutorials designed to help a developer create Fuel plugins. See https://wiki.openstack.org/wiki/Fuel/Plugins for the current version, and stay tuned for an updated version of the SDK.
Why should you validate your plugin?
Any developer interested in expanding Fuel functionality can create a plugin and use it; validation is not necessary.There is a business reason for validation, however. If you want to confirm that your plugin is compatible with a particular version of MOS and publish it to the Fuel plugin catalog on Mirantis’ site, you need to go through the validation process. The greatest benefit here is a high level of trust from Mirantis’ Solution Architects and from Mirantis’ customers.
You can read about what the Fuel plugin validation process includes, but let’s spend some time explaining how this process works and why.
During Fuel plugin validation, Mirantis acts as a core reviewer. The Fuel plugin SDK says, “Here are the rules for writing, testing, documenting and maintaining plugins.” If you don’t plan to validate your plugin with Mirantis, it’s up to you to follow or not follow those recommendations. But if you plan on taking advantage of validation, these recommendations become requirements you need to meet.
The Fuel plugin SDK provides different types of templates (for code, for documents, for CI, etc.), but designing, developing, testing and documenting every unique part of a plugin is a developer’s responsibility. Here's a look at the relative responsibilities of the Fuel plugin developer versus Mirantis:
| Fuel plugin developers are responsible for adequate design and code quality of Fuel plugins they create. | Mirantis will review a Fuel plugin design specification and then will recommend improvements. |
| Fuel plugin developers are responsible for test coverage, test automation and the auto build process. | Mirantis will review your Test Plan, Test Report and your CI design, providing feedback and help if needed. |
| Fuel plugin developers are responsible for creating extensive supporting documentation. | Mirantis will review the User Guide and provide comments. |
| Fuel plugin developers are responsible for releasing a plugin that works and meets customer needs. | Mirantis will run User Acceptance testing and let you know if there are bugs present. Plugins with numerous and critical bugs can’t pass validation and won’t be recommended to customers. |
Limitations
Fuel plugin validations cannot guarantee that all plugins will meet all customer use cases. But Mirantis makes sure the plugin works the way it’s described in the User Guide and makes sure all limitations are documented.Sometimes a client-based Mirantis project team faces a situation when a validated plugin does not fully meet customer requirements. It’s completely normal: most Mirantis customers have large installations, and some requirements can be quite exotic, while some plugins have only MVP functionality. In this case, it may be necessary to add features to the plugin, or even to write a new one. In this case, the Mirantis project/deployment team connects with the Fuel plugin’s maintenance team and decides how to proceed.
Fuel plugins and Mirantis OpenStack
Fuel plugins are not a part of the MOS distribution. They must be downloaded separately from the Mirantis Fuel Plugin Catalog (if a user is interested in a validated plugin). A plugin is a set of puppet manifests performing a set of pre-deployment or post-deployment actions, including package installation.Fuel is open source (as part of OpenStack Big Tent), and developers are advised to keep plugin code open source, too, though packages can be proprietary. For example, the Juniper Contrail Fuel plugin is not open source. (The Fuel community also recommends publishing plugins in DriverLog to keep a record of existing plugins.)
So what happens if users want to deploy MOS with Juniper Contrail SDN as a Neutron backend? In this case, they need to download the Fuel plugin from the Mirantis Fuel Plugin Catalog and then buy the Juniper Contrail packages from Juniper. Juniper Contrail bits should be downloaded and stored in a repository from which the Fuel plugin will get them before deployment and configuration.
Other important steps of the validation process
As you may have realized, the Fuel plugin validation is a complex process that comprises several stages. For example, one important step we haven’t mentioned yet is making a demo.The demo serves several purposes:
- It shows the plugin in action
- It provides a knowledge transfer on what the plugin does, how it works and what limitations it has
There's also the matter of User Acceptance (Partner Acceptance) testing. In this case, the Mirantis validation team receives a Fuel plugin rpm package. Then, in either a Mirantis’ or a partner's lab, we install Fuel and the Fuel plugin, deploy an environment according to the steps described in the User Guide and perform actions according to the Test Plan.
Basically we are testing repeating the user's journey to make sure it is successful. If we see any inconsistencies or bugs, we ask partners to fix them.
All validated plugins (both an rpm and a set of documents) are published in the Mirantis Fuel plugin catalog.
Why we do it
From the outside, the process seems complex, and our validation requirements may seem too strict. But for those who know how the OpenStack community works, there’s nothing new in the development standards validation follows.Mirantis believes that our strength is in integration with partners, and our customers should rely on these integrations.
The Mirantis Validation team is always ready to help all plugin developers succeed. We are constantly contributing to the Fuel plugin SDK and answering questions in IRC chats (on Freenode at #fuel-dev), the OpenStack mailing list, and on the unlocked-tech@mirantis.com mailing list.
