Open Stack

I'd like another term as Nova PTL, if you'll have me.

I feel Kilo has gone reasonably well for Nova -- our experiment with
priorities has meant that we’ve got a lot of important work done. We
have progressed well with cells v2, our continued objects transition,
scheduler refactoring, and the v2.1 API. The introduction of the
trivial bug review list at the mid-cycle meetup has also seen 123 bug
fixes merged since the mid-cycle, which is a great start.

Kilo is our second release using specs, and I think this process is
still working well for us -- we’re having fewer arguments at code
review time about the fundamentals of design, and we’re signalling to
operators much better what we’re currently working on. Throughout Kilo
I wrote regular summaries of the currently approved specs, and that
seems to have been popular with operators.

We also pivoted a little in Kilo and created a trivial approval
process for Kilo specs which either were very small, or previously
approved in Juno. This released the authors of those specs from
meaningless paperwork, and meant that we were able to start merging
that work very early in the release cycle. I think we should continue
with this process in Liberty.

I think its a good idea also to examine briefly some statistics about specs:

Juno:
   approved but not implemented: 40
   implemented: 49

Kilo:
   approved but not implemented: 30
   implemented: 32

For those previously approved in Juno, 12 were implemented in Kilo.
However, we’ve now approved 7 specs twice, but not merged an
implementation. I’d like to spend some time at the start of Liberty
trying to work out what’s happening with those 7 specs and why we
haven’t managed to land an implementation yet. Approving specs is a
fair bit of work, so doing it and then not merging an implementation
is something we should dig into.

There are certainly priorities which haven’t gone so well in Kilo. We
need to progress more on functional testing, the nova-network
migration effort, and CI testing consistency our drivers. These are
obvious things to try and progress in Liberty, but I don’t want to
pre-empt the design summit discussions by saying that these should be
on the priority list of Liberty.

In my Kilo PTL candidacy email, I called for a “social approach” to
the problems we faced at the time, and that’s what I have focussed on
for this release cycle. At the start of the release we didn’t have an
agreed plan for how to implement the specifics for the v2.1 API, and
we talked through that really well. What we’ve ended up with is an
implementation in tree which I think will meet our needs going
forward. We are similarly still in a talking phase with the
nova-network migration work, and I think that might continue for a bit
longer -- the problem there is that we need a shared vision for what
this migration will look like while meeting the needs of the deployers
who are yet to migrate.

Our velocity continues to amaze me, and I don’t think we’re going
noticeably slower than we did in Juno. In Juno we saw 2,974 changes
with 16,112 patchsets, and 21,958 reviews. In Kilo we have seen 2,886
changes with 15,668 patchsets and 19,516 reviews at the time of
writing this email. For comparison, Neutron saw 11,333 patchsets and
Swift saw 1,139 patchsets for Kilo.

I’d like to thank everyone for their hard work during Kilo. I am
personally very excited by what we achieved in Nova in Kilo, and I’m
looking forwards to Liberty. I hope you are looking forward to our
next release as well!

Michael

-- 
Rackspace Australia