Oslo Goals for Kilo Cycle
In the past, the PTL of each project has been responsible for selecting summit sessions based on proposals collected from the community. For this summit, most of the core teams have worked together to discuss and develop the session list for their tracks. I’m happy with the outcome for Oslo – it was a lot less work for me personally than the last two summits have been, and we have a better list of topics than I would have picked on my own without so much direct input from the rest of the team.
Going into the planning sessions, we knew we would be continuing to work on graduating more code from the incubator, but all of the other topics came from suggestions collected via etherpad.
Oslo graduation schedule
Which modules are ready to graduate and what order do they need to be done?
- Where can we find more reviewers?
- What do we do to keep the drivers up to date? Should they move to their own source trees?
- How can we get python 3 support?
- What is the relationship between oslo.messaging and kombu?
A Common Quota Management Library
We have a few different groups that want to revamp quota management. What should a shared quota library look like, and how should we develop it?
- How can we recruit more reviewers for taskflow?
- Should some of its features lib in other libraries?
Using alpha versioning for Oslo libraries
We use alpha version numbers on Oslo libraries during the middle of the release cycle. There are a lot of objections to the use of alpha version numbers, so we want to go over the reasons for using them, and for not using them.
Python 3 support in Oslo
Status, blockers, and plans for work in kilo.
Moving Oslo away from namespace packages
Should we? How do we do it?
Other Kilo Work
Because of limited time and space at the summit, there were some projects we were not able to set aside time to discuss. These are either understood well enough that we don’t need to talk about them face-to-face, or they are not high priorities.
Below are a few of the highlights, and as with most of the other projects, we are using gerrit to review design documents (or “specs”) so check there for the complete details: https://review.openstack.org/#/q/project:openstack%2Foslo-specs,n,z
Changes to oslo.config
We had a couple of groups propose changes to the way oslo.config stores options. Obfuscation or encryption of configuration options has come up several times in the past, without a real concrete proposal for a useful implementation, so we’re saving this topic until we have a spec written up. We’ve also had suggestions to use a configuration service, instead of reading files from the local filesystem. It’s likely that some sort of plugin system for oslo.config could be used to meet both of these needs.
Bring in the nova.objects package
About a year ago Dan Smith proposed nova.objects for incubation. At that time I had some issues with the implementation, and I never followed up with him. In the intervening time, the code has evolved and stabilized quite a bit so this cycle we are going to move it directly to a library. There is a spec up for review.
Improvements to oslo.db
Cache Configuration Library
Tooz is a library for coordinating work between distributed processes, including abstractions for locking and group management that are implemented on top of a plugin-based system allowing different deployers to use different backends. The library was developed by a few OpenStack developers on stackforge, and the Oslo team has agreed to adopt and help maintain it, pending working out the details.
Looking over the list of topics, I identified a couple of themes for us this cycle.
We need to add more team members.
We have a couple of libraries (taskflow and oslo.messaging) that still see quite a bit of active development and need more reviewers. We will need to be careful when adding the tooz and versionedobjects libraries that we also bring along reviewer teams for them. Gerrit is configured to allow separate review teams for each library, so we can have specialists on a library without requiring them to commit to the work that a member of the overall oslo-core team commits to doing. This has worked well for oslo.db, but we need to find interested reviewers for the new libraries.
Continue with graduation.
It’s possible we will finish the major graduation push this cycle. We still have a fair amount of cleanup to do in the code to be graduated, and we have the previously-mentioned need for more reviewers, but most the remaining code has fewer users than the low level libraries we worked on during Juno.
We have learned with a couple of hard transitions that when changes need to be made they must come slowly but steadily. Several of the proposed changes this cycle are incremental enhancements to existing code.
Rely on our liaisons.
The liaison program started during the Juno cycle worked out very well for the projects that participated. They will be an important part of our future success as well.