Partners and the Mirantis Unlocked validation program -- Part 1: Plugins
- 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.
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.
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.
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.
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.
