Mirantis Unlocked validation program. Part 2: Hard and Soft
Authors: Evgenia Schumacher, Ilya Stechkin
We present to your attention the second material on the validation programs that Mirantis offers to its partners. In the last post, we talked about who and why you need to validate fuel-plugins. Today we will talk about the validation of applications and hardware.
This story is more about Linux. Because the main task of the Hardware compatibility program is to verify that Linux sees the specific hardware and can work with it. It would seem that everything is more or less simple: if Linux sees, then OpenStack sees. But...
')
Suppose we have a server model with specific network cards and we check that MOS (read Ubuntu, because this is the host OS for the cloud infrastructure in our distribution) sees this hardware and networking (networking) cards. There is an industry-accepted term HCL (Hardware Compatibility List) - a list of software and hardware compatibility with the operating system. Why can't we just take an “external” list, for example, from Canonical ? The fact is that Fuel, the main MOS deployment tool (Mirantis OpenStack), uses the bootstrap-images mechanism.
So, the Fuel master node finds all the servers that are connected to it and starts the process of provisioning. It lies in the fact that the node is bootstrap image, which can be set by the operator Fuel. Yes, you can install any custom package from the default repository or connected external storage using the script fuel-bootstrap builder. How it works, you can find out here (do not be afraid, the link is English, of course, but there is a lot more code than idle chatter).
And only a few steps after this, the host operating system is installed. Thus, checking the “classic version” of the operating system is not enough, because the properties of the bootstrap image can sometimes differ from it. It is possible, returning to the beginning of the article, a situation in which Ubuntu “sees” the network card, and the bootstrap does not.
Of course, Mirantis does not produce an operating system. But due to the technological features of the MOS deployment, we are forced to create a kind of HCL in order to protect our users from unpleasant surprises.
But since Mirantis OpenStack today is one of the most popular OpenStack distributions, obviously, hardware vendors are interested in getting into our list - this is their way to introduce themselves to users. The validation procedure for these companies is quite simple and is described in detail on our website . And we can recommend to users to get acquainted with the list of “trusted suppliers” of equipment and check whether manufacturers of the “hardware” at your disposal fall into it.
Of course, in 99% of cases, Ubuntu HCL works for MOS, especially since it contains more detailed information than in MOS HCL.
Therefore, we always recommend that you first look at our HCL, but be sure to check it out in Ubuntu HCL too. Still, Linux vendor knows better.
Let's start with a description of what “applications” are in terms of MOS (Mirantis OpenStack). From the point of view of where the applications “live”: running on virtual machines in the cloud (in cloud applications) and complementary MOS (running alongside cloud). Applications running in the cloud are of two main types: those that are suitable for working in the cloud (cloud native applications), and those that were created without taking into account the growing popularity of cloud solutions. The latter can be integrated into OpenStack-cloud, but this will have to work hard.
Let's talk about in-cloud applications. They “live” on virtual machines that are connected to a cloud that is managed, for example, using OpenStack, on servers in the data center that Jack built. Or Vasya. Or someone else.
How to put the application on a virtual machine? First you need to create it (VM), then install an operating system on it, and the next step is to install the application. This can be done in the “old-fashioned way” - with the help of the Glance image, which contains both the operating system and the application. It would seem, what's the validation? So ...
Suppose you have an application that you would like to validate. We propose to create a Glance image for it, and then do the exercise described above using the MOS managed infrastructure (Mirantis OpenStack - by the way , the ninth version of the distribution kit has just been released). We are an infrastructure provider. You provide a Glance image and deploy it on a VM running MOS. The task of the validation process is to confirm the fact that your application works correctly with MOS.
But after all, for some applications you will need more than one virtual, but several running services. How to automate something at the application level? At this level of the stack, Murano-images and Heat-patterns come to the rescue.
But what about the other applications, those who are “neighbors”?
Let's look at an example of applications that live next to OpenStack. For example, Talligent (billing). For us, this is also an application, since it is not embedded in OpenStack at the infrastructure level (via OpenStack drivers), but interacts with the cluster at the API level (via external protocols). Talligent collects statistics on the use of the cloud: it, for example, refers to Nova to get information about the number of virtual machines created in a particular tenant by a specific user.
Such applications do not have a direct relationship to the application validation process, but we work with them anyway. They have 2 ways to integrate with OpenStack in general and with MOS in particular. The first way is to put the application in manual mode: deploy the cluster under the control of MOS, deploy Talligent and ask the engineers to configure the interaction between them. The second method is a fuel plugin. In the second case - see our posts about the development of fuel-plug-ins and their validation.
If we have described the process of validating fuel plug-ins or open-stack drivers in detail, from the perspective of experts who know exactly how to integrate into the OpenStack infrastructure, in the case of applications we do not (yet) have such expertise. Validation of applications involves a clear separation of roles: we provide the infrastructure, and the vendor (application developer) is testing its offspring on this infrastructure. Therefore, at the first stage of validation, we communicate a lot with the developer / vendor of applications, discuss what is needed in order to show that the application really works stably.
Take the trendy example - NFV (Network Function Virtualization). The essence of the technology is to replace the hardware with an application running in a virtual machine. There is such a solution - Virtual SBC ( Session Border Controller - Session Border Controller ) - the development of Metaswitch, very demanded by telecommunication companies. It can be run on a virtual machine managed including OpenStack. We (Mirantis) cannot say how to check the quality of the work of this application (we are not experts), but we can make OpenStack work the way this application needs.
The vendor VNF application imposes certain infrastructure requirements. We satisfy these requirements by setting up the infrastructure necessary for testing the application. Then the partner installs the application and tests it according to the Test Plan written by him. We finally look at the test results provided by the vendor.
In terms of providing NVFI (Network Function Infrastructure), the following scenarios are possible: the infrastructure for this application can be configured manually or automatically (for example, to enable the Huge Pages option). It may be that you can manually configure the infrastructure (shuffling with OpenStack configuration files), and the application will work correctly, and you can automatically configure the cloud configuration as VNF requires, that is, a specific version of Fuel (OpenStack deployment tool and subsequent cloud management) may not support the setting of parameters required by this application. Such details are always described in a document that is an important artifact of the validation process - a runbook.
The main idea of ​​certification - we say to the vendor: “Show us the numbers and test cases ... Put your application on our infrastructure and prove that it actually works.”
More details on the application validation procedure can be found here .
Unfortunately, today there are no certification marks in the Community Application Catalog . But we are planning to create our own catalog of validated applications. And right now this information can be found on our website in the partner directory. However, we are convinced that a mark on certification under a certain distribution will increase the level of customer satisfaction (customer satisfaction) and will help avoid conflicts of expectations and reality. Therefore, we hope that the Community App Catalog team will hear our recommendations and add the ability to label validated applications.
We present to your attention the second material on the validation programs that Mirantis offers to its partners. In the last post, we talked about who and why you need to validate fuel-plugins. Today we will talk about the validation of applications and hardware.
"Iron logic
This story is more about Linux. Because the main task of the Hardware compatibility program is to verify that Linux sees the specific hardware and can work with it. It would seem that everything is more or less simple: if Linux sees, then OpenStack sees. But...
')
Suppose we have a server model with specific network cards and we check that MOS (read Ubuntu, because this is the host OS for the cloud infrastructure in our distribution) sees this hardware and networking (networking) cards. There is an industry-accepted term HCL (Hardware Compatibility List) - a list of software and hardware compatibility with the operating system. Why can't we just take an “external” list, for example, from Canonical ? The fact is that Fuel, the main MOS deployment tool (Mirantis OpenStack), uses the bootstrap-images mechanism.
So, the Fuel master node finds all the servers that are connected to it and starts the process of provisioning. It lies in the fact that the node is bootstrap image, which can be set by the operator Fuel. Yes, you can install any custom package from the default repository or connected external storage using the script fuel-bootstrap builder. How it works, you can find out here (do not be afraid, the link is English, of course, but there is a lot more code than idle chatter).
And only a few steps after this, the host operating system is installed. Thus, checking the “classic version” of the operating system is not enough, because the properties of the bootstrap image can sometimes differ from it. It is possible, returning to the beginning of the article, a situation in which Ubuntu “sees” the network card, and the bootstrap does not.
Of course, Mirantis does not produce an operating system. But due to the technological features of the MOS deployment, we are forced to create a kind of HCL in order to protect our users from unpleasant surprises.
But since Mirantis OpenStack today is one of the most popular OpenStack distributions, obviously, hardware vendors are interested in getting into our list - this is their way to introduce themselves to users. The validation procedure for these companies is quite simple and is described in detail on our website . And we can recommend to users to get acquainted with the list of “trusted suppliers” of equipment and check whether manufacturers of the “hardware” at your disposal fall into it.
Of course, in 99% of cases, Ubuntu HCL works for MOS, especially since it contains more detailed information than in MOS HCL.
Therefore, we always recommend that you first look at our HCL, but be sure to check it out in Ubuntu HCL too. Still, Linux vendor knows better.
Applications: “sky-high” and cloud
Foreword
Let's start with a description of what “applications” are in terms of MOS (Mirantis OpenStack). From the point of view of where the applications “live”: running on virtual machines in the cloud (in cloud applications) and complementary MOS (running alongside cloud). Applications running in the cloud are of two main types: those that are suitable for working in the cloud (cloud native applications), and those that were created without taking into account the growing popularity of cloud solutions. The latter can be integrated into OpenStack-cloud, but this will have to work hard.
Let's talk about in-cloud applications. They “live” on virtual machines that are connected to a cloud that is managed, for example, using OpenStack, on servers in the data center that Jack built. Or Vasya. Or someone else.
How to put the application on a virtual machine? First you need to create it (VM), then install an operating system on it, and the next step is to install the application. This can be done in the “old-fashioned way” - with the help of the Glance image, which contains both the operating system and the application. It would seem, what's the validation? So ...
Validation of in-cloud applications
Suppose you have an application that you would like to validate. We propose to create a Glance image for it, and then do the exercise described above using the MOS managed infrastructure (Mirantis OpenStack - by the way , the ninth version of the distribution kit has just been released). We are an infrastructure provider. You provide a Glance image and deploy it on a VM running MOS. The task of the validation process is to confirm the fact that your application works correctly with MOS.
But after all, for some applications you will need more than one virtual, but several running services. How to automate something at the application level? At this level of the stack, Murano-images and Heat-patterns come to the rescue.
Neighbor Applications
But what about the other applications, those who are “neighbors”?
Let's look at an example of applications that live next to OpenStack. For example, Talligent (billing). For us, this is also an application, since it is not embedded in OpenStack at the infrastructure level (via OpenStack drivers), but interacts with the cluster at the API level (via external protocols). Talligent collects statistics on the use of the cloud: it, for example, refers to Nova to get information about the number of virtual machines created in a particular tenant by a specific user.
Such applications do not have a direct relationship to the application validation process, but we work with them anyway. They have 2 ways to integrate with OpenStack in general and with MOS in particular. The first way is to put the application in manual mode: deploy the cluster under the control of MOS, deploy Talligent and ask the engineers to configure the interaction between them. The second method is a fuel plugin. In the second case - see our posts about the development of fuel-plug-ins and their validation.
Boundaries of opportunity
If we have described the process of validating fuel plug-ins or open-stack drivers in detail, from the perspective of experts who know exactly how to integrate into the OpenStack infrastructure, in the case of applications we do not (yet) have such expertise. Validation of applications involves a clear separation of roles: we provide the infrastructure, and the vendor (application developer) is testing its offspring on this infrastructure. Therefore, at the first stage of validation, we communicate a lot with the developer / vendor of applications, discuss what is needed in order to show that the application really works stably.
Take the trendy example - NFV (Network Function Virtualization). The essence of the technology is to replace the hardware with an application running in a virtual machine. There is such a solution - Virtual SBC ( Session Border Controller - Session Border Controller ) - the development of Metaswitch, very demanded by telecommunication companies. It can be run on a virtual machine managed including OpenStack. We (Mirantis) cannot say how to check the quality of the work of this application (we are not experts), but we can make OpenStack work the way this application needs.
The vendor VNF application imposes certain infrastructure requirements. We satisfy these requirements by setting up the infrastructure necessary for testing the application. Then the partner installs the application and tests it according to the Test Plan written by him. We finally look at the test results provided by the vendor.
In terms of providing NVFI (Network Function Infrastructure), the following scenarios are possible: the infrastructure for this application can be configured manually or automatically (for example, to enable the Huge Pages option). It may be that you can manually configure the infrastructure (shuffling with OpenStack configuration files), and the application will work correctly, and you can automatically configure the cloud configuration as VNF requires, that is, a specific version of Fuel (OpenStack deployment tool and subsequent cloud management) may not support the setting of parameters required by this application. Such details are always described in a document that is an important artifact of the validation process - a runbook.
The main idea of ​​certification - we say to the vendor: “Show us the numbers and test cases ... Put your application on our infrastructure and prove that it actually works.”
More details on the application validation procedure can be found here .
Conclusion: external signs of validation
Unfortunately, today there are no certification marks in the Community Application Catalog . But we are planning to create our own catalog of validated applications. And right now this information can be found on our website in the partner directory. However, we are convinced that a mark on certification under a certain distribution will increase the level of customer satisfaction (customer satisfaction) and will help avoid conflicts of expectations and reality. Therefore, we hope that the Community App Catalog team will hear our recommendations and add the ability to label validated applications.
Source: https://habr.com/ru/post/307470/
All Articles