Comments in line (added my thoughts on a couple of the targets Sean outlined).
On Thursday, September 4, 2014, Sean Dague <s...@dague.net> wrote: > > > 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). > > Big +1 from me on this. > 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. > > I agree here as well. we should prioritize logging and use that success as the template for the other southbound parts. If we get profiler, notifications, etc it is a win, but hitting logging hard and getting it right is a huge step in the right direction. > 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. > > I like the concept but I absolutely want a definition on what micro versioning should look like. That way we don't end up with 10 different implementations of micro versioning. I am very concerned that we will see nova do this in one way, neutron in a different way, and then other projects taking bits and peices and ending up with something highly inconsistent. I am unsure how to resolve this consistency issue if multiple projects are implementing during the same cycle since retrofitting a different implementation could break the API contract. Generally speaking the micro versioning will be much more maintainable than the current major API version methods. > 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 > Cheers, --Morgan
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
