Mirantis Unlocked validation program. Part 2: Hard and Soft

    Authors: Eugene Schumacher, Ilya Stechkin We

    present to your attention the second material devoted to the validation programs that Mirantis offers to its partners. In the last post, we talked about who and why fuel plugins should be validated for. Today we’ll talk about application and hardware validation.

    "Iron logic




    This story is more about Linux. Because the main task of the Hardware compatibility program is to verify that Linux sees specific hardware and can work with it. It would seem that everything is more or less simple: if Linux sees, then OpenStack sees. However ...

    Suppose we have a server model with certain network cards and we verify that MOS (read Ubuntu, because it is the host OS for the cloud infrastructure in our distribution) sees this hardware and these network cards. There is the industry-accepted term HCL (Hardware Compatibility List) - a list of software and hardware compatibility with the operating system. Why can't we just take the “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 provisioning process. It consists in the fact that a bootstrap image is placed on the node, which can be set by the Fuel operator. Yes, yes, you can install any custom package from the default repository or connected external storage using the fuel-bootstrap builder script. You can find out how it works here (do not be afraid, there is an English link, of course, but there is a lot more code there than empty talk).

    And only a few steps after this is the installation of the host operating system. 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” a network card, but 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 to protect our users from unpleasant surprises.

    But since Mirantis OpenStack is one of the most popular OpenStack distributions today, obviously the hardware vendors are interested in getting to our list - this is their way to recommend themselves to users. The validation procedure for these companies is quite simple and described in detail on our website . And we can recommend users to get acquainted with the list of “trusted suppliers” of equipment and check whether the 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 into our HCL, but be sure to check in Ubuntu HCL too. Still, the Linux vendor knows better.

    Applications: sky-high and cloud




    Foreword


    Let's start by describing what “applications” are from the point of view of MOS (Mirantis OpenStack). From the point of view of where the applications “live”: they run on virtual machines in the cloud (in cloud applications) and complement MOS (running alongside cloud). Applications running in the cloud are of two main types: those that are adapted to work 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 you will have to work hard for this.

    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 the operating system on it, and the next step is to install the application. You can do this in the “old-fashioned way” - using the Glance image, which contains both the operating system and the application. It would seem, what does validation have to do with it? So ...

    Validation of in-cloud applications


    Suppose you have an application that you would like to validate. We suggest creating a Glance image for it, and then doing the exercise described above using the infrastructure managed by MOS (Mirantis OpenStack - by the way, a new, ninth version of the distribution has just been released ). We are an infrastructure provider. You provide a Glance image and deploy it to 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 not one virtual machine, but several running services. How to automate something at the application level? At this stack level, Murano images and Heat templates come to the rescue.

    Neighbor Applications


    But what about other applications, those that are “neighbors”?

    Let's look at an example of applications that live next to OpenStack. For example, Talligent (billing). This is also an application for us, since it is not implemented 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: for example, he calls Nova to get information about the number of virtual machines created in a particular tenant by a specific user.

    Applications of this kind are not directly related 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 - you can put the application in manual mode: deploy a cluster running MOS, deploy Talligent and ask the engineers to configure the interaction between them. The second way is a fuel plugin. In the second case - see our posts about the development of fuel-plugins and their validation.

    Boundaries of opportunity


    If we described the process of validating fuel plug-ins or open-driver drivers in detail, speaking from the position of experts who knew exactly how to integrate into the OpenStack infrastructure, then in the case of applications we (so far) do not have such expertise. Validation of applications involves a clear separation of roles: we provide the infrastructure, and the vendor (application developer) tests his brainchild on this infrastructure. Therefore, at the first stage of validation, we talk a lot with the application developer / vendor, discuss what is needed to show that the application really works stably.

    Let's take a fashionable example - NFV (Network Function Virtualization). The essence of the technology is to replace the “iron” telecom with an application running on a virtual machine. There is such a solution - Virtual SBC (Session Border Controller (Session Border Controller ) - Metaswitch development, which is very popular among telecommunication companies . It can be run on a virtual machine, which is also managed by OpenStack. We (Mirantis) cannot say how to check the quality of this application (we are not experts), but we can make OpenStack work as this application needs.
    The VNF application vendor has specific infrastructure requirements. We satisfy these requirements by setting up the infrastructure necessary for testing the application. Next, the partner installs the application and tests it according to the Test Plan written by him. In the end, we 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, enable the Huge Pages option). It may be that you can manually configure the infrastructure (by messing with the OpenStack configuration files), and the application will work correctly, and you can’t automatically configure the cloud because it requires VNF, that is, a specific version of Fuel (OpenStack deployment tool and subsequent cloud management) May not support setting the parameters required by this application. Such details are always described in the document, which is an important artifact of the validation process - runbook.

    The main idea of ​​certification - we tell the vendor: “Show us the numbers and test cases ... Put your application on our infrastructure and prove that it actually works.”

    You can learn more about the application validation procedure here .

    Conclusion: external signs of validation


    Unfortunately, to date, no certification marks have been placed in the Community Application Catalog . But we plan to create our own catalog of failed applications. And right now this information can be found on our website in the partner directory. However, we are convinced that the certification mark for a particular distribution will increase the level of customer satisfaction (customer satisfaction) and avoid conflicts of expectations and reality. Therefore, we hope that the Community App Catalog team will hear our recommendations and add the ability to mark failed applications.

    Also popular now: