OpenStack Days are community events with a mixed audience of operators, vendors and people interested in the cloud generally. They are organised independently in different regions around the world and the most recent UK edition took place in London on September 26th.

There were speakers from the OpenStack Foundation, from prominent suppliers of OpenStack services and from users, including representatives from the UK academic community. The opening keynote was from Thierry Carrez, VP of engineering at the Foundation discussing “The Four Opens” and how they apply to OpenStack:

• Open source
• Open development
• Open design
• Open community

He also addressed the increasing complexity in the OpenStack ecosystem and provided an excellent start to the day. The subsequent keynote talks from AVI Networks, Red Hat, Canonical and Mellanox addressed automation and networking.

The rest of the schedule was split across different rooms, and here are my impressions from the talks I attended. Two speakers from Huawei presented the latest developments of the Kuryr project in OpenStack which integrates Neutron with Docker and Kubernetes, to present network services to containers running in an OpenStack cloud, thereby allowing a more cloud-native approach. Kuryr uses the Dragonflow distributed SDN controller, which allows for good scaling (as demonstrated in tests with Redis) and now supports OpenFlow pipelines in OpenvSwitch. Interesting, it achieves these scaling improvements by running on the compute nodes themselves. Recent efforts have extended Kuryr to embrace Kubernetes, including a controller and CNI driver. Where possible, these components re-use as much as possible of the existing OpenStack infrastructure, such as Keystone for authentication/authorization and projects within Nova. When Kubernetes pods are running inside VMs, the speaker advised using trunk ports to avoid the performance penalty of double packet encapsulation. The next developments for Kuryr will include – scaling for controllers as well as for ports, multi-network support and performance improvements. This was a very useful overview, including reports of performance testing – a feature often missing in such presentations.

Next was Tim Cutts presenting on the work at Sanger on Secure Lustre with OpenStack. Their approach, given the large legacy of existing scientific pipelines that make conservative assumptions about the infrastructure on which they’re running (e.g. POSIX file access), is to regard traditional HPC clusters and cloud computing as complementary, with the latter providing a flexible compute environment. Those workloads need to be supported as the level of cloud provision increases, giving time for them to be re-written with a cloud-native architecture. While they now have 14PB of Ceph storage (4.5PB usable), they needed to be able to use the very large datasets hosted on local Lustre resources, and to provide good security isolation between tenants when doing so. Tim described their work, which relied on new features only available since Lustre 2.9. Using one bare-metal Lustre router shared amongst all the tenants, they achieved 3GB/second aggregate performance across multiple clients. For greater isolation, they have also implemented a separate virtualised router for each tenant. Some wrinkles they found are that they needed to turn off port security, which is an acceptable tradeoff in a fairly tightly controlled environment, and that there is some inadvertent asymmetric routing by Lustre, which implies it does not check the origin of packets sufficiently. More details of their work are available at https://hpc-news.sanger.ac.uk/ and there is a video of a similar talk at ISC17.

Prometheus has been adopted as a supported project for monitoring by the Cloud Native Computing Foundation, and it is often discussed in connection with Kubernetes. I was interested to hear about monitoring OpenStack with Prometheus, in a talk by Csaba Patyi of Component Soft. OpenStack is composed of many services, each with their own logs, making the logging and monitoring situation quite complex. Csaba demonstrated how to use the well-established Elastic Stack for OpenStack. This works well, is easily configurable and does not require Logstash. However, it can be hard to separate data from metadata and extra work is needed to handle multi-line logs, which are quite common in OpenStack. He showed how you can manipulate logs based on their information structure, which enables useful views in Kibana and for the creation of dashboards based on log information. The code for the demo environment used in the talk is available on GitHub. For monitoring and alarming he discussed Prometheus, which was created by design for cloud environments. Advantages he mentioned are that there are lots of Prometheus data exporters for OpenStack, and that it can be configured to search via DNS for new hosts, rather than relying upon static configuration.

My first talk in the afternoon session was on High Availability, by Kenneth Tan of Sardina Systems. Kenneth began by highlighting the new expectations that users have, based on their exposure to public cloud services such as AWS, and by pointing out the different perspectives that consumers of services have, as opposed to operators of those services. The first safeguard needed for high availability is to take an infrastructure-as-code approach, allowing for easy redeployment, whereas a simple safeguard for data is to use replication. He discussed the differences between extrinsic and intrinsic ‘death risks’ and the need to detect and distinguish what he termed ‘sick states’ e.g. when a node is affected but not dead – it is ‘unhealthy’. He emphasised the importance of looking for correlations and causality in monitoring data, and in looking for anomalies. Pushed data streams are better for scaling than polling, he suggested. The infrastructure implications of storing metrics and logs were listed, along with the need for systems that can handle unbalanced I/O patterns i.e. large numbers of small writes, along with a small number of very large reads. With good monitoring you should be able to predict imminent faults, and deal with latent threats, before they become patent threats.

OpenStack as a project has not been immune from the remorseless spread of containers, and one of the more interesting aspects for me has been the effort to allow running OpenStack services as containers. Steve Hardy from Red Hat gave a talk entitled “Deploying OpenStack at Scale with TripleO, Ansible and Containers” which discussed the changes in the TripleO project to accommodate exactly such containerisation of services, and to make more use of Ansible in general for deployments. TripleO creates a small OpenStack installation (“the undercloud”) which is then used to install the main installation (“the overcloud”). Historically it largely used Puppet for all the installation tasks, and lacked some flexibility, which made it harder than it should have been to customise deployments to meet local requirements. Node roles in TripleO are now composable and the Mistral project effectively provides an API for TripleO as a whole. One of the benefits of containerisation includes dependency isolation, which makes it much easier to roll backwards and forwards with different versions. TripleO has been collaborating with the Kolla community on this effort. He also mentioned the Paunch tool which manages the containers used by TripleO.

Link to talk PDF.

The final talk I attended in the technical tracks was by Julien Danjou, who is one of the developers in the Gnocchi project. Gnocchi was created when it became clear that Ceilometer lacked the performance required for time-series data, in large part because it was originally designed for billing and included a lot of flexibility that was irrelevant for monitoring. Some interesting features of Gnocchi are that it computes metric aggregations itself, that it can batch measurements together and send them in a single HTTP request, and horizontal scaling is achieved by simply adding more nodes. He referred to recent performance testing in Gnocchi version 4, described on his blog at https://julien.danjou.info/blog/2017/gnocchi-4-performances. It’s an interesting alternative to the more generic monitoring approaches listed above.

Link to talk PDF.

The final talk was by Jonathan Bryce, who is the Executive Director of the OpenStack Foundation. This was quite informal and in part a Q&A, particularly useful for people new to the OpenStack community.

It was a packed day and as always I could only see a fraction of the talks I wanted to attend. A convenient way of catching up with the latest developments, seeing how people are using OpenStack, and meeting familiar faces in the community.