Berlin Summit Recap

Since there was only one Oslo session and a couple of Designate sessions that I was able to attend, this update is going to be a bit of a grab-bag of topics. Hopefully I have some interesting thoughts on them. :-)

Oslo Project Update

This one should be pretty self-explanatory, but unfortunately the video isn't posted yet. According to the Foundation site they should be available mid-December. I'll update this post when that happens.

In the meantime, the slides are available right now.

[UPDATE] And of course just as I publish this the remainder of the Summit videos go up. :-)

Here's the Oslo project update

Image Encryption Library

There is currently a group working on end-to-end image encryption in OpenStack. This is to say that they want to be able to upload an image that has been encrypted on the client side, store that image in Glance, and then have Nova/Cinder/etc. decrypt it as needed. There are more details on the etherpad for image encryption code.

It turns out that this is a rather tricky thing to do because it crosses so many project boundaries. It requires support in Glance, Nova, Cinder, openstackclient, and openstacksdk. It also means each of those projects needs some amount of image encryption code, and we obviously don't want to duplicate it across all of them. Sounds like a job for Osloman! (coming soon to a theatre near you)

Actually, it's not quite as simple as that. There are libraries that could be used for this, but some of them are not very maintained. Others have a long list of dependencies, which is problematic for things like the sdk and client that ideally should be lightweight. As of this writing there is extensive discussion around how to handle this in the oslo spec. If you have interest or input on this topic please do weigh in there.

Storyboard Migration

We had another good discussion about this in Berlin. Other than the lack of attachment support in Storyboard (which there is a story to address), many of the major blockers seem to be resolved. There was still quite a bit of discussion around usability of things like search and new story creation, but I don't see those as blockers for migrating Oslo.

Attachments may be an issue as I believe there are some existing Launchpad bugs with attachments. For migration purposes we can always refer back to the original Launchpad bug, but at the moment it would mean that users couldn't upload any new attachments. Before we pull the trigger on the migration, the Oslo team will need to have a discussion around how important attachments are.

The main thing that has been holding us up so far is lack of migration of bug triage information. This is important to me, especially since I spent quite a bit of time over the past couple of cycles getting the untriaged bug list in Oslo down to a manageable size. I'd rather not lose that work when we migrate to Storyboard. Fortunately, the Storyboard team was very receptive to adding priority migration support to the existing tool, so hopefully this won't be an issue much longer. I should also note that Doug Hellmann has written a script for updating story tags based on imported priority. If we run that against all of the imported stories it should do what we want, although ideally it would be integrated into the migration tool itself so everyone benefits.

Designate

There was both a design session for shared zones as well as a project feedback session for Designate. Unfortunately I'm a bit light on details because I can't find the etherpads for either. On a very basic level, Graham was willing to help spec out new features, but wasn't going to have time to implement them. Fortunately, there was a verbal commitment in the room to have people assigned to work on some of the feature requests.

If/when I find the etherpads (I'm pretty sure they exist) I'll add more to this section.

Concurrency Limits

This ended up being long enough that I thought it deserved its own post.

Community Goals for Train

Lots of good options, not many that were 100% ready to be a community goal as of this discussion. This is important because we've repeatedly gotten feedback on the goals that it is very unhelpful when something is made a goal, but the pre-work for the goal hasn't been done yet so it becomes a moving target. You can find details on the session etherpad for all of them. Hopefully someone can champion a couple of them so they are ready to go by Train.

I will also take this opportunity to discuss number 12 on the etherpad since I talked about it in the session. It's actually Graham Hayes' idea, but during the goals session he was giving the Designate project update (once again Designate was the last session of the Summit :-). In short, he has proposed improvements to the oslo.middleware healthcheck to make it more useful for containers and root cause analysis. Currently the healthcheck does little more than verify that the REST API of a service is responding and possibly provides some details about the status of the service (which may or may not be good, depending on your security stance. The detail behavior is disabled by default for that reason). Graham's proposal is to extend that so the healthcheck can also verify things like database or messaging access. Service-specific plugins could be provided for services that need to talk to backends so they could verify those connections as well.

The benefit of doing this is that pretty much every modern container ecosystem expects to be able to healthcheck the application running in a container. This allows them to automatically handle service outages to some extent, and right now the healthchecks being used with OpenStack services are fairly ad-hoc and limited. Providing a single method of running healthchecks would be a big improvement. In addition, the self-healing SIG is interested because this healthcheck architecture could be used for root cause analysis. If your healthchecks are reporting on specific aspects of a service's connectivity then it can be helpful in tracing a problem back to its source. As a simple example, if you have an outage and see in your healthcheck logs that 18 services lost their connection to rabbitmq at the same time you know that you should probably start looking at rabbitmq.

Fortunately, the oslo.middleware healthcheck already supports plugins, so Graham has protoyped some changes that would allow the existing middleware to behave as needed. However, he probably won't have time to push this through to completion, so consider this post a bit of a call for help as well. If this sounds like something you'd be interested in, please contact the Oslo team and we can discuss how to move forward.

Given that this is firmly in the "good idea, but not ready" category for Train goals, I currently wouldn't push for it to be selected as a goal. However, I did want to get it some visibility because I think it's something we should do in the near future.

Conclusion

And once again I ended up having way more to say about Summit than I realized when I started writing. :-)

I hope this was interesting and if you have any comments/questions/good knock-knock jokes (only good ones!) don't hesitate to contact me.