Validation of Fuel Plugins within the Mirantis Unlocked validation program. Do you need it?
Authors: Evgenia Schumacher, Ilya Stechkin
Hello. Yes, if you like money, then you need it. Next we will explain what “validation of plugins” is and why it is useful for business. If you have no business interests, and programming is a way of self-expression, then you can stop reading.
And if you decide to read, then let's first recall what Fuel and Fuel plug-ins are (see blog posts from August and October 2015). User surveys show that Fuel is a very popular OpenStack deployment tool. The ability to create plug-ins appeared in Fuel, starting with version 6.1. It was necessary to allow users to arbitrarily expand the functionality of this cloud deployment tool. Previously, this could be done exclusively during the work on the code of the project itself. The introduction of plug-ins has allowed users to customize Fuel, bypassing the complex process of making changes to the “core” of the project.
')
However, even today, users still have the opportunity to contribute to the development of Fuel directly. But this is another story, not related to the topic of our article. It is easier to extend the functionality of Fuel with the help of plug-ins, because in this case it is not necessary to go through a million cycles of the applet of blueprints (for the definition of terms, see the Contributor Dictionary ), etc. The fact is that the plugin itself is a project that you manage yourself ( for example, how Mellanox does it ).
Terms not found in the dictionary:
Fuel plugin framework is an architectural term that says that the product is designed in such a way that its functionality can be extended with the help of plug-ins.
Fuel plugin SDK (Software Development Kit) - a set of tools, practices, documents and training materials that help the developer create plug-ins for Fuel. The current version is available here , although it will soon move here , see commit ). The basis of this toolkit is based on the rules derived from the analysis of best practices for developing and implementing plug-ins. To validate a plugin, you must follow these rules. A feature of OpenStack is the responsibility of the developer to follow the rules of the community. If any initiative is proposed without following the relevant procedures adopted in the community (for example, the establishment of the blueprint), it is guaranteed not to be accepted. In the case of plugins for Fuel, developers have more freedom. The need to strictly follow the “best practices” arises only if it is intended to validate the plugin. For example, you need to monitor compliance with the standards developed for free licenses (mainly Apache 2.0): Fuel is an open project. So the official plug-ins for Fuel must also be open. However, for your own needs, you can develop and use unvalidated plugins.
A driver log is a plug-in directory for OpenStack components that is managed by the developer community.
There is a business aspect to validation. If you officially receive confirmation that your plug-in works with MOS (Mirantis OpenStack), it will be published not only in Driverlog (which is highly recommended, already more than 30 plug-ins for Fuel are officially known to the community, although in fact there are much more, just we do not know about them), but also on the Mirantis website , so that our company's clients know about it and can use your product in their solutions.
In this case, Mirantis acts as a kind of “corrector”. We say: "Here are the rules for writing plugins." If for some reason you decide not to follow these rules, this is your right. Until you decide to go through the validation procedure. But if you go to validation, then we read your code and we can put both +1 and -1. That is, we can recommend improvements to the code. We check the documentation (for validation, it is necessary to document the plugin in a certain way - see the SDK). In addition, you must provide us with your CI, including test scripts and its results. We will definitely conduct our own tests for your scenarios. And their results should coincide with those that you provided.
MOS variants with validated plug-ins can be taken to support by Mirantis support together with the plug-in developer (i.e. Mirantis will answer the client’s call, but if there is a problem with the functionality provided by Fuel plug-in, the support request will be sent to the plug-in developer).
Validation does not mean that we guarantee that the plugin is suitable for all clients and all MOS installations. The developer of the plugin determines the specific user case (use case), and also describes the limitations in the operation of the plugin. Mirantis, on the other hand, checks the correctness of the plug-in's work within a specific use case (use case). There is always a risk that the plugin will not suit a particular client.
The plugin is written, documented, successfully validated, our company's specialists or client are interested in using the plugin, but ... In the process, it turns out that the client has very specific deployment requirements. And the plugin does not fit. Thus, validation does not guarantee that the plugin will suit all customers. It may be necessary to add or rewrite a plugin.
In such cases, the implementation team contacts the plugin support team and asks for the necessary code refinements in order to extend the functionality of the plugin.
It is important to remember that no plugin is part of the MOS distribution. The latter does not include any plugin. Plugins need to be downloaded separately. This is a set of puppet manifests packaged in rpm format that allows you to put packages in a specific order. This part should be open. At the same time packages that are placed by the plugin can be proprietary and be the object of sale. For example, Juniper Contrail. In order to use this plugin, you need to purchase from Juniper the right to use Juniper Contrail packages, specifying the number of nodes and configuration when purchasing. Only after the client places the purchased packages at a specific address, MOS (using the plugin) will be able to access them.
Validation is a complex process consisting of several stages:
1. Providing a specification (“specs”) that describes the design of the plugin.
2. Review code. Of course, in practice we do not give “ratings” to a validated plugin, but we give our comments. The developer has the right to ignore our comments. But a situation is possible in which the validation process will not be completed until changes are made.
3. Review of documentation. Developers should provide the following package of documents:
- The user guide is the most important document containing information about how and why to use the plugin, what are the restrictions on its use, which “life hacks” will be useful to the user and which “pitfalls” he can meet.
- Test plan.
- Test report. The last two documents allow us to verify the completeness of coverage of the yuzkeys tests.
Templates have been developed for all the documents mentioned above. They are part of the Fuel Plugin SDK.
As for tests, we distinguish two types: general / mandatory and specific. We expect partners to add unique test scripts to their test plan. In addition, partners must build their CI and develop automated tests to simplify the procedure for assembling and testing plug-ins.
The test report, in turn, allows us to compare our test results with what you have.
In order to make this comparison, we completely repeat the path of the “nameless user” - we ask you to send the plugin in the form of a package and on your lab (or partner’s lab) we consistently carry out all the steps from the developer’s guide. After that, we take a test plan and selectively pass through the tests. Thus, we get an idea of how true the results of the test report are. Usually this procedure allows you to catch a large number of bugs. There has never been a case for us to have any comments. Sometimes these are routine edits, but there are also critical errors that need to be corrected before publication. Some partners consider us too strict. But we are convinced that the strength of Mirantis lies in the reliability of the proposed solutions.
4. We ask partners to show us the plug-in in real time. This allows a) all interested Mirantis units to get acquainted with the plugin and b) clearly demonstrates the performance of the proposed solution.
At the end of the validation process, we publish the plugin in our partner directory. The developer can also independently publish it in the driverlog .
From the outside, the process seems complicated, but for those who are familiar with how the community works, there is nothing new here. Our team responsible for working with partners helps all plugin developers succeed. We are not only developing the SDK, but always ready to answer questions. To contact us, use IRC chat on freenode.net (the common channel of Fuel is #fuel, the channel of the developers of Fuel is # fuel-dev, the channels for the developers of the main components of Fuel: # fuel-library, # fuel-python, # fuel-ui , # fuel-qa, # fuel-infra. Gerrit notifications for all Fuel repositories are available here: # fuel-tracker), you can also use the mailing address unlocked-tech@mirantis.com . More information here .
Hello. Yes, if you like money, then you need it. Next we will explain what “validation of plugins” is and why it is useful for business. If you have no business interests, and programming is a way of self-expression, then you can stop reading.
Plugins as part of the architecture of Fuel
And if you decide to read, then let's first recall what Fuel and Fuel plug-ins are (see blog posts from August and October 2015). User surveys show that Fuel is a very popular OpenStack deployment tool. The ability to create plug-ins appeared in Fuel, starting with version 6.1. It was necessary to allow users to arbitrarily expand the functionality of this cloud deployment tool. Previously, this could be done exclusively during the work on the code of the project itself. The introduction of plug-ins has allowed users to customize Fuel, bypassing the complex process of making changes to the “core” of the project.
')
However, even today, users still have the opportunity to contribute to the development of Fuel directly. But this is another story, not related to the topic of our article. It is easier to extend the functionality of Fuel with the help of plug-ins, because in this case it is not necessary to go through a million cycles of the applet of blueprints (for the definition of terms, see the Contributor Dictionary ), etc. The fact is that the plugin itself is a project that you manage yourself ( for example, how Mellanox does it ).
Terms not found in the dictionary:
Fuel plugin framework is an architectural term that says that the product is designed in such a way that its functionality can be extended with the help of plug-ins.
Fuel plugin SDK (Software Development Kit) - a set of tools, practices, documents and training materials that help the developer create plug-ins for Fuel. The current version is available here , although it will soon move here , see commit ). The basis of this toolkit is based on the rules derived from the analysis of best practices for developing and implementing plug-ins. To validate a plugin, you must follow these rules. A feature of OpenStack is the responsibility of the developer to follow the rules of the community. If any initiative is proposed without following the relevant procedures adopted in the community (for example, the establishment of the blueprint), it is guaranteed not to be accepted. In the case of plugins for Fuel, developers have more freedom. The need to strictly follow the “best practices” arises only if it is intended to validate the plugin. For example, you need to monitor compliance with the standards developed for free licenses (mainly Apache 2.0): Fuel is an open project. So the official plug-ins for Fuel must also be open. However, for your own needs, you can develop and use unvalidated plugins.
A driver log is a plug-in directory for OpenStack components that is managed by the developer community.
Why are you still interested in validating the plugin?
There is a business aspect to validation. If you officially receive confirmation that your plug-in works with MOS (Mirantis OpenStack), it will be published not only in Driverlog (which is highly recommended, already more than 30 plug-ins for Fuel are officially known to the community, although in fact there are much more, just we do not know about them), but also on the Mirantis website , so that our company's clients know about it and can use your product in their solutions.
In this case, Mirantis acts as a kind of “corrector”. We say: "Here are the rules for writing plugins." If for some reason you decide not to follow these rules, this is your right. Until you decide to go through the validation procedure. But if you go to validation, then we read your code and we can put both +1 and -1. That is, we can recommend improvements to the code. We check the documentation (for validation, it is necessary to document the plugin in a certain way - see the SDK). In addition, you must provide us with your CI, including test scripts and its results. We will definitely conduct our own tests for your scenarios. And their results should coincide with those that you provided.
MOS variants with validated plug-ins can be taken to support by Mirantis support together with the plug-in developer (i.e. Mirantis will answer the client’s call, but if there is a problem with the functionality provided by Fuel plug-in, the support request will be sent to the plug-in developer).
Restrictions
Validation does not mean that we guarantee that the plugin is suitable for all clients and all MOS installations. The developer of the plugin determines the specific user case (use case), and also describes the limitations in the operation of the plugin. Mirantis, on the other hand, checks the correctness of the plug-in's work within a specific use case (use case). There is always a risk that the plugin will not suit a particular client.
The plugin is written, documented, successfully validated, our company's specialists or client are interested in using the plugin, but ... In the process, it turns out that the client has very specific deployment requirements. And the plugin does not fit. Thus, validation does not guarantee that the plugin will suit all customers. It may be necessary to add or rewrite a plugin.
In such cases, the implementation team contacts the plugin support team and asks for the necessary code refinements in order to extend the functionality of the plugin.
It is important to remember that no plugin is part of the MOS distribution. The latter does not include any plugin. Plugins need to be downloaded separately. This is a set of puppet manifests packaged in rpm format that allows you to put packages in a specific order. This part should be open. At the same time packages that are placed by the plugin can be proprietary and be the object of sale. For example, Juniper Contrail. In order to use this plugin, you need to purchase from Juniper the right to use Juniper Contrail packages, specifying the number of nodes and configuration when purchasing. Only after the client places the purchased packages at a specific address, MOS (using the plugin) will be able to access them.
Stages of the validation process
Validation is a complex process consisting of several stages:
1. Providing a specification (“specs”) that describes the design of the plugin.
2. Review code. Of course, in practice we do not give “ratings” to a validated plugin, but we give our comments. The developer has the right to ignore our comments. But a situation is possible in which the validation process will not be completed until changes are made.
3. Review of documentation. Developers should provide the following package of documents:
- The user guide is the most important document containing information about how and why to use the plugin, what are the restrictions on its use, which “life hacks” will be useful to the user and which “pitfalls” he can meet.
- Test plan.
- Test report. The last two documents allow us to verify the completeness of coverage of the yuzkeys tests.
Templates have been developed for all the documents mentioned above. They are part of the Fuel Plugin SDK.
As for tests, we distinguish two types: general / mandatory and specific. We expect partners to add unique test scripts to their test plan. In addition, partners must build their CI and develop automated tests to simplify the procedure for assembling and testing plug-ins.
The test report, in turn, allows us to compare our test results with what you have.
In order to make this comparison, we completely repeat the path of the “nameless user” - we ask you to send the plugin in the form of a package and on your lab (or partner’s lab) we consistently carry out all the steps from the developer’s guide. After that, we take a test plan and selectively pass through the tests. Thus, we get an idea of how true the results of the test report are. Usually this procedure allows you to catch a large number of bugs. There has never been a case for us to have any comments. Sometimes these are routine edits, but there are also critical errors that need to be corrected before publication. Some partners consider us too strict. But we are convinced that the strength of Mirantis lies in the reliability of the proposed solutions.
4. We ask partners to show us the plug-in in real time. This allows a) all interested Mirantis units to get acquainted with the plugin and b) clearly demonstrates the performance of the proposed solution.
At the end of the validation process, we publish the plugin in our partner directory. The developer can also independently publish it in the driverlog .
Conclusion
From the outside, the process seems complicated, but for those who are familiar with how the community works, there is nothing new here. Our team responsible for working with partners helps all plugin developers succeed. We are not only developing the SDK, but always ready to answer questions. To contact us, use IRC chat on freenode.net (the common channel of Fuel is #fuel, the channel of the developers of Fuel is # fuel-dev, the channels for the developers of the main components of Fuel: # fuel-library, # fuel-python, # fuel-ui , # fuel-qa, # fuel-infra. Gerrit notifications for all Fuel repositories are available here: # fuel-tracker), you can also use the mailing address unlocked-tech@mirantis.com . More information here .
Source: https://habr.com/ru/post/303522/
All Articles