Partners and the Mirantis Unlocked validation program — Part 1: Plugins

Evgeniya Shumakher, Ilya Stechkin - April 22, 2016 -

Business partnerships are so often about common marketing activities such as co-branding, cross-promotion and the publication of joint press releases, but Mirantis is first and foremost a technology company, and very serious about the technical and engineering solutions we produce. That means that the Mirantis Unlocked Partnership Program is about creating common technical solutions.

Of course, because we’re involved in so many different areas of OpenStack, we’ve found that these solutions covered a lot of ground. In all, we have identified three levels of integration with OpenStack: the hardware level, the infrastructure level and the application level — and each needs its own validation program. In this series of posts, we’re going to discuss those different programs and what they mean for both vendors and end users.

Three types of OpenStack validation

The validation program for hardware vendors such as Dell, SuperMicro, Quanta, and so on helps those vendors to show their clients that their hardware is tested and works with MOS (Mirantis OpenStack). We offer validated hardware configurations, which include a bill of materials (BoM) to show the recommended hardware unit (or model) for a particular role (such as a compute node, controller node, or storage node).

At the infrastructure level (for example, for Cinder it can be an integration with EMC VNX or other appliances, or with SDS (Software Defined Storages) like ScaleIO) we offer OpenStack Driver validation for manual integration and Fuel Plugin validation for automated deployment.

Finally, at the application level, we offer application validation for those who create products that run on OpenStack VMs. This program is most interesting to partners who create products to run in virtual environment, such as Virtual Network Functions (VNFs). These products are organised as Murano packages or Glance images and we strongly recommend that you publish these solutions at the Community App Catalog to ease the validation process. Complimentary applications such as Zabbix or Talligent, that are using OpenStack API, can also be validated as part of this program.

Now let’s discuss, in detail, the benefits of each program, starting with OpenStack plugin validation.

OpenStack plugin validation

We started with OpenStack plugin validation in 2014 because at that moment a huge number of vendors interested in OpenStack at the infrastructure level. They have software, hardware or hybrid solutions under OpenStack’s governance, such as storage that serves as a backend for Cinder OpenStack component. For example, NetApp, and Solidfire as a part of NetApp, need a Cinder driver, Juniper Contrail needs a Neutron driver (or a plugin), and so on. But still there is a question: why are vendors interested in validation?

Imagine you are and end user. You might be thinking, “I’m going to build a cloud, but I don’t know what storage backend I should choose. Should I choose a hardware appliance or a SDS (software-defined storage)? Or both?” So who do you ask?

Well, your cloud provider would be a good choice, especially if they are vendor-neutral. For example, Mirantis will advise you based on your particular use case and the data we’ve obtained from the various validation programs.

Now of course, if you’re a vendor and you have a number of tested solutions for different use-cases, you have a better chance of being the recommendation from the cloud-provider. So if you are a vendor, you are interested in the validation program to get the client.

What is the OpenStack plugin validation process?

As we mentioned before this validation is designed for partners integrating with MOS on the infrastructure level.

The prerequisite for this process is an OpenStack driver or a plugin, that is adopted by OpenStack community. DriverLog is a source of truth for plugins and drivers for different OpenStack components.

Ok, a plugin is developed, upstreamed and published in DriverLog. What’s next?

The exact process varies according to the actual situation, of course. But in general the integration between the partner’s technology and MOS is done manually in the lab.

Let’s say we have a partner with a SDS solution (per example, Solifire). They would like to demonstrate that instead of the standard storage back-end that Fuel can deploy MOS can work with their product.

First step is to design a joint RA (Reference Architecture). Mirantis Partner team will work with a partner to identify a target use cases and target user personas and help a partner to define a solution that they will validate.

Before moving to the next step a partner should make sure they have all necessary hardware that’s configured properly. Mirantis Unlocked program can provide a partner with a lab if they don’t have their own (here is how).

Next step is to download the latest version of MOS from here and deploy a new environment with Fuel (we recommend to go with an HA (High Availability) as this is something Mirantis customers have in production).

Next step is to manually replace one solution with another. In case of our SDS partner they might need to manually replace LVM as a Cinder storage back end with their product. Which will mean that they need to install their product, connect it to MOS environment and reconfigure it, so Cinder with use this SDS instead of Ceph (in most cases it means that a partner needs to install a Cinder driver and to change some Cinder config files). And the most difficult part is done.

As soon as everything is installed, a partner runs tests (using Tempest and Rally or any other test tool that they have), and then prepares a runbook, which is a complete step-by-step manual that enables any MOS user to get the same results. This document should be related to a particular Mirantis OpenStack release.

Experience shows us that the lifetime of each release is not longer than two years, but we ask our partners to keep their solutions relevant for each new release. That means that it’s preferred that you test your solution every six months, and you must renew the validation once a year.

Next time, we’ll talk about the Fuel plugin validation program.

From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
How is Cloud Native Changing the Landscape of Edge and 5G? [Recording]

Late last year, Mirantis hosted a Cloud Native and Coffee panel featuring CTO Adam Parco, Global Field CTO Shaun O’Meara, Director of Technical Marketing Nick Chase, and special guest Darragh Grealish, CTO of 56K Cloud. Below are highlights of the discussion that touch on what edge is and how developers can bring cloud native innovation to edge computing and 5G. Watch …

How is Cloud Native Changing the Landscape of Edge and 5G? [Recording]
Moving to Cloud Native: How to Move Apps from Monolithic to Microservices

Enterprises face the challenge of consistently deploying and managing applications in production, at scale. Fortunately, there are more technologies and tools available today than ever before. However, transitioning from a traditional, monolithic architecture to a cloud native one comes with its own unique challenges. Below, you will find a list of the critical first steps you need to take when …

Moving to Cloud Native: How to Move Apps from Monolithic to Microservices
Mirantis Newsletter - January 2022

Every month, Mirantis sends out a newsletter chronicling top industry and company news. Below you’ll find links to blogs, tutorials, videos, and the latest updates to our enterprise, open source, and training offerings. If you don’t currently receive the newsletter, you can subscribe by clicking the button on the top right. Mirantis Brings Secure Registries to Any Kubernetes Distro Launched earlier this …

Mirantis Newsletter - January 2022
The Definitive Guide to Container Platforms
Getting started with Kubernetes part 2: Creating K8s objects with YAML

Thursday, December 30, 2021 at 10:00 AM PST
Mirantis Webstore
Purchase Kubernetes support