Oslo Goals for Kilo Cycle

Next week is the OpenStack design summit kicking off the Kilo
release cycle. The Oslo team has seven sessions scheduled to hash
out details of the work we will be doing between now and May.

Summit Sessions

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

Wed, 5 Nov 11:00

Which modules are ready to graduate and what order do they
need to be done?


Wed, 5 Nov 11:50

  • 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

Wed, 5 Nov 13:50

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?


Thu, 6 Nov 11:50

  • How can we recruit more reviewers for taskflow?
  • Should some of its features lib in other libraries?

Using alpha versioning for Oslo libraries

Thu, 6 Nov 13:40

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

Thu, 6 Nov 16:40

Status, blockers, and plans for work in kilo.

Moving Oslo away from namespace packages

Thu, 6 Nov 17:20

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

The oslo.db team has several big improvements planned, including
enhancements to the test fixtures, supporting MySQL connector
for better eventlet performance, and better Alembic support.

Cache Configuration Library

We approved a spec for Juno to create a configuration library to make
dogpile.cache easier to use. That was never implemented, and has
been resubmitted for kilo.

Adopt tooz

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.

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

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

  3. Steady evolution.

    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.

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