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:
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
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
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.