Ask anyone who has actually operated an OpenStack system what the biggest complication is (once they’ve decided on system components and architecture), and you’ll hear muted complaints about having to tweak puppet, or frustrations in manipulating the Ansible code to get just the system they want. At the Silicon Valley OpenStack Operators Meetup this evening, we saw the solution that Canonical has been working on over the last few years, and they’ve finally built something that looks like it addresses many of the asks for many OpenStack systems operators. The basic concept presented at the meetup was that there are two main challenges in getting an OpenStack system running: 1) getting the base operating system and operating system configuration onto the physical machines that are to become a part of the environment, and 2) getting the actual application (or in our case middleware) installed and properly configured. Other issues such as upgrades are often left to the end user to figure out, but even in this case Canonical has a solution, even if they were clear that upgrades are still delicate operations that are often best left to services professionals who can focus on ensuring that everything goes smoothly.
@Canonical offer's #Juju + #MAAS as a solid #OpenStack operations enablement toolset Click To Tweet
To address step 1) getting the systems properly configured, Canonical showcased their latest version of MAAS (http://maas.io/), or Metal As A Service, which runs on a VM or physical server of it’s own. This part of the platform does systems discovery (power on the physical servers that you want MAAS to manage and a DHCP/PXE combination loads a discovery OS), resource allocation (selecting from systems based on user applied tags and platform capabilities like processor type), and is then, as it’s name implies, a service for providing “bare metal” as a service to other users via API, CLI, or web interface. It was pointed out that currently the bare metal aspect focuses mostly on the compute subsystem, and doesn’t get into management of local storage or the physical network configuration (in fact the system assumes that these configurations are pre-applied or use default configurations).
@Canonical #MAAS simplified bring-up of bare metal servers Click To Tweet
Given that most OpenStack deployments configure the network via SDN like techniques (if not via full SDN based controllers), this isn’t such an issue on the network side, but could become an issue at least for initial bring-up in the case of a need to change the factory default storage configuration. Once MAAS is ready to deliver phyiscal servers (although in reality it’ll just as happily manage pre-congfigured virtual machines, or anything else that you can implement a power management and PXE boot mechanism on), it’s time to hand the reins over to the heavy weight orchestrator in this system: Juju.
Names aside (MAAS I get, Juju, yeah, ok, but, wait, really?), Juju’s (https://jujucharms.com/) role is to automate tasks, and it does this via Charm’s it’s packaging model for it’s automation elements (which can also be bundled). One of Juju’s interested capabilities, which maps well to use via an optional GUI based interface, is the fact that Juju provides simple connectivity modeling. Simply defining a connection (assuming of course that one is possible in the charm itself), will enable automation of the connectivity configuration needed for a particular connection. As with most configuration management systems today, Juju is idempotent (you can re-run the same tasks and get the same results), and restartable, so it’s possible to fix a system if something gets out of kilter, or if something caused the automation to fail.
@Canonical #Juju provides automation & meta-automation, simplifying the connectivity between multi-service applications Click To Tweet
But getting back to our OpenStack installation. If we deploy our physical (and any virtualized sub-systems we might want to manage via MAAS) systems and hand them to Juju, using the OpenStack Juju bundle of charms, it’s possible in short order to get an OpenStack service running. So far, not much fanfare on that topic, seen it, Devstack’s done it. But it gets interesting when you look at then upgrading to a later version of OpenStack, and here, it gets interesting, because in a “basic” OpenStack environment, it’s possible to re-run the juju deployment changing only the target for the version of the OpenStack services, and have the system upgrade to the newer release! If a non-HA model was chosen for the initial platform, there will be service components that experience an outage as their services are restarted, but that shouldn’t impact running _actual_ VMs, and in fact should fit many use cases where service outages can be managed through management windows and similar. With an HA based deployment, it is likely that no service disruptions will be noticed at all!
Certainly Juju and MAAS are not the answer to every possible scenario, and there are still areas that were not well covered in the demonstration that are important to operators, such as the model for monitoring the system after deployment. In addition, large system providers are still likely on the right track to treat OpenStack as a set of web-scale software applications that should be deployed via CI/CD techniques. But for the larger number of operators and deployers who want to enable OpenStack for their users and still be able to have a life after hours, it seems like this is a very reasonable choice!