csuttles (⌐■_■)

Memento Mori

Automate Everything It's important to automate all the things you can to make your workflow efficient and error free. It's easy to miss a step in a runbook or let a typo ruin your testing. Enter Rally I think best way to test changes is via CI/CD, and Rally is the tool that's used for gating changes to OpenStack in OpenStack's Zuul. Even if you are not commiting code to OpenStack, Rally can help you validate changes to your environment.

There's a lot of posts on this already: https://www.openstack.org/news/view/340/openstack-pike-delivers-composable-infrastructure-services-and-improved-lifecycle-management https://www.mirantis.com/blog/53-things-to-look-for-in-openstack-pike/ https://www.theregister.co.uk/2017/09/01/openstack_pike_release_emphasises_microservices_and_scale/ Here's what I'm excited about in this release. Python3 There are a lot of good things in the Pike release, but I am very excited to see the move to Python3.5. I stopped writing Python2.x a while ago, after reading about async in Dave Beazley's excellent Python column in :login;. I'm fortunate to work in a place that really embraces Python's new features, and fully supports Python3, so this change is huge for me, because I don't have to write Python2 anymore at all.

Pip won't do it I recently installed OpenStack using Kolla into a single node at home for testing the latest beta of the Pike release. When I decided to install python-openstackclient on my Mac, I ran into some problems. I ran sudo pip install python-openstackclient and things looked like they were working normally, until a wild traceback appears: Installing collected packages: pbr, monotonic, iso8601, netifaces, netaddr, pyparsing, Babel, oslo.i18n, wrapt, debtcollector, oslo.

What happened? In an OpenStack instance with a single controller, using Galera and RabbitMQ for clustered database and message queue, the controller failed. I still had the message queue and database on the other nodes, but thanks to a looming timeline, pressure from management, and my own mistakes, I ended up with a SD card backing some key logical volumes. The SD card died, and thus, I am rebuilding the controller from nothing.

Docs, Pitfalls, and First Steps The Kolla OpenStack project is focused on deploying OpenStack in containers. There's a good quickstart guide, but like most things OpenStack, you'll need to dig a little deeper if you want to be successful. You can deploy an all-in-one, or multinode instance of OpenStack with Kolla; the latter requires a local Docker registry, so even for an all-in-one deployment, I chose to create a local registry, so that I might be better prepared when the time came to move to multinode.

Docs The start of this journey begins with docs, and understanding the model for running containers in Nomad. I ran through the examples and found it pretty easy once I got going. Why You might expect the "Why" to be the first step, and really, it is. We chose Nomad because IPv6 is a serious requirement for our installation, I work with a brilliant guy who happens to be a Nomad contributor.

While setting up Galera on IPv6 only as part of our move toward multiple controller nodes, I ran into a few challenges. This post explains those challenges and how I dealt with them. Resources I used and config reference I found some good references on the web. The most useful ones including the following: OpenStack HA Guide This very helpful blog post MariaDB/Galera Downloads MariaDB/Galera Docs I also looked at:

Neutron Pain Points Kevin Benton https://www.openstack.org/summit/boston-2017/summit-schedule/events/18801/neutron-pain-points https://etherpad.openstack.org/p/neutron-boston-painpoints https://etherpad.openstack.org/p/pike-neutron-making-it-easy Octavia LBaaS People were looking for an update on status, but noone was there to speak on it Main contributor moved on, but project is still maintained, even though it was not represented in this session FWaaS v2 L3 supported since Newton L2 was targeted for Ocata, now targeted for Pike

Oslo Developer/Operator Feedback ChangBo Guo https://www.openstack.org/summit/boston-2017/summit-schedule/events/18762/oslo-developeroperator-feedback https://etherpad.openstack.org/p/BOS-Oslo-brainstorming This was a brainstorming dev/user session for the oslo middleware that unifies communications between OpenStack components. Topics included testing against PyPy, configs in etc.d (or potentially consul), messaging and potential changes to rootwrap and privsep. A suggestion to better support alternatives to RabbitMQ for AMQP messaging in this forum bore fruit in the next oslo forum and are detailed in this etherpad: https://etherpad.

Containers Networking Using Kuryr: A Hands-On Lab Sudhir Kethamakka Amol Chobe https://www.openstack.org/summit/boston-2017/summit-schedule/events/18385/containers-networking-using-kuryr-a-hands-on-lab Kuryr is a part of the OpenStack Big Tent Kuryr is a bridge between container frameworks and Neutron Supports CNI and CNM Docker Kubernetes Rkt CoreOS The lab focused on the CNM model. Both CNM and CNI support are plugins in Kuryr, so it's possoble to extend Kuryr to support other network models by writing a plugin at this layer.