Becoming an OpenStack-Related Project

My main area of focus for Kayobe recently has been the move to become an OpenStack-related project. This is the current name for non-official projects that use OpenStack infrastructure - much like the 'big tent'.

There were a number of factors that lead to this, including:

• promote wider adoption through conformity
• use of OpenStack's excellent Continuous Integration (CI) infrastructure

The OpenStack project creator's guide is a long read, with many serialised steps. Thankfully not all steps were applicable, and the infrastructure was up and running relatively quickly - thanks infra team!

The headline changes for users and developers of Kayobe are:

• Bugs and features are now tracked via Storyboard, rather than Github. Storyboard is OpenStack's shiny new task management tool, and will be gradually replacing Launchpad which is no longer supported by Canonical.
• Code changes are submitted via Gerrit, rather than Github pull requests.
• Code changes are tested via Zuul, rather than TravisCI.

Testing & Continuous Integration (CI)

Over time we built up a set of CI jobs for Kayobe in TravisCI. It's an impressive service - they provide free CI for any public repository on Github, with pull request integration. A full control plane deployment test remained elusive however. TravisCI provides only Ubuntu 12.04 and 14.04 as test instance images, and these releases are no longer supported by OpenStack. We tried installing Kayobe in a Docker container, but continued to hit issues.

While moving to OpenStack's infrastructure, I started reading up on Zuul v3. The latest release of the project uses a simple in-repo job definition syntax based on YAML. Jobs are implemented using Ansible, and a form of inheritence is supported that allows jobs to be built up in layers and reused. Zuul is currently going through the process of becoming a project in its own right - still under the OpenStack Foundation umbrella, but separate from OpenStack. Hopefully this will increase adoption of this great tool.

At the time of writing, Kayobe has 10 Zuul jobs, including one for deploying a single node control plane, and one for deploying a seed host. We still have a way to go to improve test coverage, but these jobs have already shown their worth and should allow us to move forward with greater confidence.

Upcoming Changes

Here are some of the work items in the pipeline:

• support for the Queens release of OpenStack
• support for development against master branch of OpenStack projects
• support more recent versions of Ansible - we're currently limited to Ansible 2.3

A feature that I'm particularly excited about is supporting extension points for custom behaviour. This will allow users to integrate their own Ansible playbooks and roles with Kayobe, and configure them to run at specific points during existing workflows. This will allow the core of Kayobe to remain small without limiting the flexibility of the tool.

Dublin PTG

I attended the snowy Project Teams Gathering (PTG) in Dublin along with other folks from StackHPC. During the Kolla sessions I presented Kayobe to the team. There was interest from a number of parties, from wanting to try out Kayobe, to considering how the two projects could collaborate in future.

I also gave a video update on the project while in Dublin. Thanks to Rich Bowen from Red Hat for putting these interviews together.

Demo!

The following demo runs through deployment of an OpenStack control plane in a Vagrant VM, using the Kayobe development environment tooling. The commands were taken from the Kayobe development guide, and it should be possible to replicate the demo on a modern laptop.

The asciicast has been edited to limit idle time to 0.5 seconds, and playback is in double time. The real time video is available here, and the single time, idle time limited video is available here.

Manchester OpenStack Meetup

Thanks to the Manchester OpenStack meetup for allowing me to speak on Kayobe recently. Always interesting to meet new folks in the community, and great to see OpenStack remains strong in Manchester. The talk was not recorded, but the slides are available.

Mark Goddard (@markgoddard86) from @stackhpc delving into Kayobe #mcropenstack pic.twitter.com/LJMASifKaf

— Danny Abukalam (@dabukalam) 12 March 2018

Kayobe's History: In the Beginning

Like many projects, Kayobe started life as a pile of shell scripts. These provided automation of Kolla Ansible to deploy the control plane for the Square Kilometre Array's (SKA) Performance Prototype Platform (P3). It soon became apparent that a more capable automation tool than bash would be required, and I switched to my old friend Ansible.

Before long, the core of Kayobe as it currently stands began to emerge, filling several gaps in Kolla Ansible:

• control plane server provisioning via Bifrost (similar to TripleO's undercloud)
• configuration of the control plane hosts
• improved support for bare metal compute node provisioning

Widening the Audience

P3 is a High Performance Computing (HPC) cluster, and Kayobe inevitably took on a HPC focus initially. We quickly realised that the project would have wider applicability, and made an effort not to restrict its use to HPC.

Kayobe's next opportunity came from Verne Global, who use it to deploy OpenStack for hpcDIRECT, their HPC-as-a-service offering powered by green Icelandic energy. Thanks to the team at Verne for their early adoption of Kayobe, allowing the project to really thrive.

I'd like to thank Kevin Tibi (IRC: ktibi) and the folks at Devoteam for seeing Kayobe's potential early on while building their CI/CD platform. This lead to the addition of support for virtualised compute, greatly widening the potential audience for Kayobe.

A Viable Alternative to TripleO

We feel that Kayobe has become a viable alternative to TripleO for users wanting to deploy an OpenStack private cloud. It provides an end-to-end solution for provisioning, reconfiguring, and upgrading the control plane.

It also provides several advantages over TripleO, including:

Simplicity

• Ansible for everything vs. many technologies in TripleO
• standalone Ironic vs. full undercloud in TripleO
• benefits of containers without using kubernetes (which is on the TripleO roadmap) - one less turtle to worry about!

Modularity

• separation of concerns - Kayobe for provisioning, Kolla Ansible for containerised OpenStack deployment
• make targeted changes, e.g. reconfigure or upgrade a specific service vs. full overcloud Heat stack update in TripleO

Extensibility

• set any OpenStack config option via Kolla Ansible
• run custom Ansible playbooks & roles (coming soon!)

Get Involved

There are many ways to get involved with Kayobe:

• read the documentation
• try out the development environment on your laptop
• say o/ on IRC: #openstack-kayobe

That's all for now, thanks for reading.

Further Reading

• Kayobe
• Kolla-Ansible
• SKA Telescope
• SKA Science Data Processor (SDP)
• Zero touch provisioning of P3