Hangover

Across the Board

Many small changes to the various OpenStack services are now occurring across the board. In the past few months, for example, the developers have massively upgraded Designate. DNS as a service is important for many end users because a website hosted on OpenStack also needs to be accessible under a brand name and not just an IP address.

For a long time, however, Designate was only capable of basic functions and, depending on the network back end selected, did not work particularly well. Today, Designate is in good shape, talking to all available SDN back ends and offering a cornucopia of features. For Yoga, the developers have focused on bug and error hunting, expanding their internal testing program and eliminating various bugs. IPv4 and IPv6, distributed name server records, and special forms of DNS records (e.g., TXT lines) have all been offered by Designate for some time. All told – perhaps more than any other OpenStack component – Designate demonstrates that today the platform's focus is on stability and reliability, not just the next big thing.

Paradigm Shift

What OpenStack developers have done recently in terms of OpenStack deployment is almost a paradigm shift of sorts. For a long time, the topic was considered external: Tools based on Ansible, Puppet, or Chef, for example, were good enough to handle OpenStack deployment. This line of reasoning crumbled quite early – at the latest, in OpenStack Ironic.

The service that establishes lifecycle management for hardware of almost any provenance in OpenStack is described as bare metal as a service. Most impressively, Ironic lets you manage OpenStack hosts like OpenStack VMs. TripleO – OpenStack on OpenStack – is the name of the construct in this case. A server running with a base OS alone is more or less meaningless to OpenStack; you need the components for it to count as OpenStack. Although they now all come in the form of containers, you still have to roll them out and configure them.

For this reason, OpenStack-Ansible is now part of OpenStack, although a separate component. It handles tasks in the TripleO context but can be equally well used standalone to get hosts ready for use with OpenStack. That this strict separation between component and deployment from the early days is no longer practiced is good and important. All told, it adds value to the OpenStack deployment.

What Is Not Better

Despite all the praise for the community making the right decisions in the recent past, OpenStack still has elements that don't work reliably or at all. Some of these can be tolerated, but others are very significant.

Today, it is good form for cloud environments to offer as-a-service services to their own user bases. OpenStack has various as-a-service components (e.g., NFS as a service, alias Manila, is well known). However, not everyone who runs a web store is an IT geek with a command line background, so services such as databases need to be accessible to less savvy users. Amazon, for example, is leading the way with its database-as-a-service offering.

OpenStack doesn't seem to be very innovative when it comes to database as a service. Although it already had a component for this service on board, in the form of OpenStack Trove, its development has been idle for more than two years, probably because the last active maintainer has since been poached by a competitor, who deleted the OpenStack topic from the new, joint portfolio shortly afterward. OpenStack users are frustrated and are forced to build their databases manually and painstakingly – if they don't immediately launch their own wild projects, as is the case in many places.

Another aspect of OpenStack that has shown a conspicuous absence of virtually all required features for many years is billing. The Ceilometer component writes user data and stores it in a database called Gnocchi. This component is a pure metric data meter and does not offer any possibility to create invoices with the acquired data.

Granted, OpenStack doesn't make things easy at this point. The complexity of the subject of billing almost implicitly ensures that you need to do more than simply collect data and generate an invoice as a PDF. Instead, it is important to pay attention to various aspects. From the customer's point of view, for example, you need to understand down to the bottom line what you are actually purchasing. If the provider claims on its invoice that a VM ran from 5:35am to 6:35am, it must be able to demonstrate this plausibly in the event of an inquiry. Moreover, various formal requirements apply to invoices, such as the obligation to number them consecutively, the correct disclosure of sales tax depending on the recipient country, and so on. OpenStack developers appear to be reluctant to deal with these details. The premise has always been that OpenStack would not handle billing and would use an external service for this purpose.

For an external service to work efficiently, OpenStack at least needs some sort of generic interface for exporting arbitrary processed data. Many companies rely on proprietary accounting tools, to which OpenStack would then of course have to connect. In practice, however, OpenStack already has a problem providing data for other services. Quite a few approaches were attempted (e.g., CloudKitty, which itself accesses data from Ceilometer); however, none of the solutions has been a resounding success, and to date only proprietary products are cobbled together for specific clouds based on OpenStack. A handful of commercial vendors have added OpenStack to their billing tools, but companies that don't use one of these tools continue to be frustrated.

If you want to run OpenStack in a way that makes sense, not only technically but also commercially, you more or less have to build the entire billing system yourself. It is high time for developers to come up with a generic interface that billing service providers can dock onto.