Introducing OpenStack through Ironic (I) Dec 12, 2015

In previous posts I have explained why I think OpenStack is great to implement an IaaS platform, but how to introduce it within a company? What is the roadmap to get it to production? A lot of people are trying to setup it in their companies as substitute of other well known virtualization platforms like VMware. I think that could be a mistake, OpenStack is not only about running VMs, do not forget that there are other open platforms available which could be suitable for small companies or pure virtualization requirements (e.g. Apache CloudStack is also great!), the scope of OpenStack is much wider than a virtualization platform: it is a sort of framework consisting in different components to build an IaaS according to the needs of the company.

I think there are two keys which can help to successfully introduce OpenStack in a company.

1. How to deploy the infrastructure needed for OpenStack?

After doing spikes, evaluations and demonstrations, the company should agree that OpenStack is the needed platform, that means assign people and resources to make it possible. The next step is designing how to build the infrastructure and services for the platform, it will need central logging, service monitoring, maybe persistent storage, etc. How to deploy and manage those services? There are some tools like Mirantis Fuel, RDO, etc. which are capable of doing almost everything, but in my opinion they are lacking of a necessary step: learning. Some people think that there is no clear way to install OpenStack, making it difficult to introduce it, others say there are a lot of different ways to do it, but they do not implement what is needed in the company or they could lead on difficulties to manage the infrastructure in the future … well, welcome to the beauty of free software: embrace diversity. I think, there will not be an universal installer for OpenStack, it is a framework, each company has to define the requirements and the way to manage it. It you think that is complicated, then I would say that OpenStack is not the tool you need, there are other platforms which could be better for you (did I mention CloudStack? :-). OpenStack is a process which will lead in improving the management of the resources in a DataCenter, it is not a product that one can just install and use. OpenStack should cause organizational changes in the company and in that sense, taking a tool to install everything and get it running is not the way to do it. It is a question about managing knowledge, one can think that knowledge is something which can be bought in a package, but, I also think that knowledge is something one should search, make it grow and finally harvest. In that sense, defining the goals and develop your own tools to reach those goals is the way to learn and give trust in the infrastructure, specially to make the most of it and mitigate the risks inherent to new technologies. OpenStack is about building knowledge and services not about unwrapping packages. I think the same applies to other platforms like PaaS.

2. Introduce the technology to the users

Thinking about use cases, there is a clear one: run VMs … but, if the company already has VMware, why forcing for a change? Well, one can say that it is expensive, others can say that there are some kind of workloads which are not needed to run on a “production” platforms, one can talk about a sort of AWS in house approach, others about licensing, standards … but, is that enough? In most of the cases, I would say no, because starting with a new technology requires effort, define a new way of working (which implies a learning curve for the people), set up new workflows with new organization of the teams, transmit knowledge to do maintenance, learn how to mitigate risks, etc. Is the company prepared for that? Why not starting with a collaboration between platforms, taking the most out of each one and fixing other specific issues?. After some personal experiences and talking with other people, I think that is the key for success. For example, Nova-compute can handle different kind of hypervisors, -one of them is the vmwareapi- so it can be connected with VMware Vcenter to see a cluster as a big hypervisor, even more, OpenStack components can be deployed within VMware itself, taking advantages of features like DRS … and what about networking? with this setup is difficult making the most of Neutron, but as starting point providing only external networks is more than enough for an introduction. With this configuration, OpenStack is just a API layer talking with VMware, easy to setup, without big risks, allowing administrators to create projects with quotas, where users can selfmanage with their favourite tooling (Terraform, Heat templates, Ansible, Bosh …) In this situation, the next step is just integrate Cinder and Glance with the VMware datastores and eventually define another hypervisors (different Availability Zones) like KVM for testing workloads. With this roadmap, people can learn mitigating risks, and finally OpenStack will have its own hardware and space within the company.

Other use case is about hardware. Companies with data-centers have servers running different operating systems and people installing in different ways, different projects and use cases (databases, logging platforms …). There are some tools around, but after using some for a few months, they tend to become a mess as more people get using them. So, question: Is there a way to avoid those problems? automating in an easy and deterministic way?, answer: Metal as a Service, there is an OpenStack component which can help, Ironic. It solves a specific issue easily: install physical servers. It can run standalone (without the rest of the OpenStack services) and it is not difficult to setup and demo, it has a restrained risk, because it is not critical service. The command line is easy to handle and understand and, the important part, it can be integrated with the current provisioning toolset (Ansible, Puppet, Chef …)

Ironic architecture diagram

Moreover, there is another important advantage with Ironic. It uses all the base architecture of OpenStack components: API process, database, message queue and workers, so it is perfect to get familiar with OpenStack, understand the workflow and from there jump to the rest of the OpenStack services. It could be a good entry point starting by deploying physical server to become a quick win for OpenStack. So, let’s go!

Related Posts