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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev