Open Stack

On 09/03/2014 11:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> Have anyone interested (especially TC members) come up with a list of
> what they think the project wide Kilo cycle goals should be and post
> them on this thread by end of day Wednesday, September 10th. After which
> time we can begin discussing the results.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.
> 
> 
> best,
> Joe Gordon
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

Here is my top 5 list:

1. Functional Testing in Integrated projects

The justification for this is here -
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html. We
need projects to take more ownership of their functional testing so that
by the time we get to integration testing we're not exposing really
fundamental bugs like being unable to handle 2 requests at the same time.

For Kilo: I think we can and should be able to make progress on this on
all integrated projects, as well as the python clients (which are
basically untested.... and often very broken).

2. Consistency in southbound interfaces (Logging first)

Logging and notifications are south bound interfaces from OpenStack
providing information to people, or machines, about what is going on.
There is also a 3rd proposed south bound with osprofiler.

For Kilo: I think it's reasonable to complete the logging standards and
implement them. I expect notifications (which haven't quite kicked off)
are going to take 2 cycles.

I'd honestly *really* love to see a unification path for all the the
southbound parts, logging, osprofiler, notifications, because there is
quite a bit of overlap in the instrumentation/annotation inside the main
code for all of these.

3. API micro version path forward

We have Cinder v2, Glance v2, Keystone v3. We've had them for a long
time. When we started Juno cycle Nova used *none* of them. And with good
reason, as the path forward was actually pretty bumpy. Nova has been
trying to create a v3 for 3 cycles, and that effort collapsed under it's
own weight. I think major API revisions in OpenStack are not actually
possible any more, as there is too much intertia on existing interfaces.

How to sanely and gradually evolve the OpenStack API is tremendously
important, especially as a bunch of new projects are popping up that
implement parts of it. We have the beginnings of a plan here in Nova,
which now just needs a bunch of heavy lifting.

For Kilo: A working microversion stack in at least one OpenStack
service. Nova is probably closest, though Mark McClain wants to also
take a spin on this in Neutron. I think if we could come up with a model
that worked in both of those projects, we'd pick up some steam in making
this long term approach across all of OpenStack.

4. Post merge testing

As explained here -
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html
we could probably get a lot more bang for our buck if we had a smaller #
of integration configurations in the pre merge gate, and a much more
expansive set of post merge jobs.

For Kilo: I think this could be implemented, it probably needs more
hands than it has right now.

5. Consistent OpenStack python SDK / clients

I think the client projects being inside the server programs has not
served us well, especially as the # of servers has expanded. We as a
project need to figure out how to get the SDK / unified client effort
moving forward faster.

For Kilo: I'm not sure how close to "done" we could take this, but this
needs to become a larger overall push for the project as a whole, as I
think our use exposed interface here is inhibiting adoption.

	-Sean

-- 
Sean Dague
http://dague.net