OpenStack summit Tokyo anyone? I've been there and thought it was a very well organized event, in a nice location. Every minute together with peers seemed worth it to me. This said, let's talk about the actual sessions. I spent most of my time at the TripleO and Heat sessions, with a little detour on Magnum. Plus some booth crawling.
- TripleO
We had three sessions and a full day meetup. The first discussed the recent work done to allow for the deployment of OpenStack in containers, using TripleO; the changes to deploy the compute nodes and a majority of the controller roles in containers are up for review, which is great; some notes can be found in the tripleo-mitaka-containers pad. It was very nice for me to see the TripleO bits delivering on the promise of being flexibile; deploying in containers requires minimal changes to the core tools and yet inherits important features like network isolation and support for Ceph.
Another session was on upgrades, which isn't a trivial goal as it pushes on both Heat and Puppet. The proposed plan is to start with a CI job attempting to upgrade an overcloud from the stable branch to the master branch; more in the tripleo-kilo-to-liberty-upgrades pad. I will hopefully write more about this topic in future posts.
There has also been a session on the CLI and UI clients. Again, not a simple problem because the Heat templates are constantly ongoing refactor to implement new features and because putting too much business logic into the client limited our flexibility in the past. We'll probably see a shared library for the newer CLI/UI, with less business logic and probably a REST API, more in the tripleo-mitaka-restapi pad.
Then the community meetup on Friday covered a few additional topics. We reviewed the status of the CI with ideas for more jobs, discussed some ideas to provision the puppet modules via Heat instead of shipping them with the images, collected lots of good feedback from actual OpenStack operators and, last but not least, discussed the recent work from Dan Prince to have composable roles. Kudos to Dan on the composable roles which also seems to work pretty well with the effort to containerize the deployment. Notes about the community meetup are in the tripleo-mitaka-meetup pad.
- Heat
I've joined only those sessions were I could at least understand the topics and yet there is quite a lot to write about. First an interesting session focused on a problem with dependencies across nested stacks, which we make large us of in TripleO. Both the issue and the consequences are much easier to understand with a picture than with words. Zane Bitter had indeed prepared some demo material for the session, including pictures, which should be linked from the mitaka-heat-break-stack-barrier pad.
Then a session to discuss issues affecting large stack deployments. Major points for discussion were of three types: token timeouts, batching of operations and resources status polling, with resources polling being probably the hardest to cope with. More in the mitaka-heat-large-stacks pad.
Then a session to collect input from users and ops. My proposal here was for the introduction of 'immutable resources' where resources with such a proerty wouldn't get deleted or updated during a stack update. One proposed solution for this is a warning message, outputted by the stack validation process, in case of resources deletion. More on this and on the session in general in the mitaka-heat-user-ops pad.
There has also been an interesting conversation about the changes from a spec meant to introduce support for external resources, which is something TripleO could use soon.
- Magnum
The Magnum project seems to be facing some of the problems which TripleO faced in past as well, in relation to the Heat templates. The goal seems to be to customize the templates based on the input parameters; I joined the session to learn more about the Magnum approach and the proposed solutions.
It seems to me that while TripleO relies on actual Heat features to allow for different implementations of the same resource, via resource registry, Magnum is working instead on a sort of pre-processor (powered by Jinja) which generates Heat templates using conditionals and includes from the Jinja language. More on this is in the launchpad bug 1501045.
- Who said installers?
It was nice to see TripleO mentioned in at least two more sessions, one where Mirantis directly compared Fuel to the Red Hat OpenStack Platform Director and another where four different automated installers were reviewed. Each had its moments.
I think one good thing about TripleO is that it is pretty flexible and offers some capabilities to maintain the environment even after the initial installation; hopefully both will make it interesting to many.
- RDO meetup
- We had a meetup for the RDO project and it cleared up a lot of questions on how the packages are built and tested for both the trunk and the stable branches. Good news is that it is now possible to try TripleO, on CentOS, with the latest RDO bits. The docs at tripleo.org are documenting exactly that.
Now, what about the event? Well, as an ATC, I have two things to say about the event more in general. First, I'd really like the design summit to start on Tuesday. Simply put, there are so many sessions going on that it is impossible to join anything out of the most immediate interests. My thinking is that one more day could at least lower parallelism!
Another comment is, please make the keynotes a little less marketish. I know the circus runs on actual money but my feeling is that the keynotes, on both Tuesday and Wednesday, left some sessions go a little too far into the product marketing area when they were probably supposed to present an actual OpenStack use case.
Last but not least, it was great to have some time to meet face to face peers and coworkers from all over the world. Including some who are not exactly peers, like Matt, to whom I ended up asking if he was a newcome to the TripleO project during dinner. I'm sure next time I will remember and do better.