Comments in line (added my thoughts on a couple of the targets Sean outlined). <span></span><br><br>On Thursday, September 4, 2014, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Here is my top 5 list:<br>
<br>
1. Functional Testing in Integrated projects<br>
<br>
The justification for this is here -<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html</a>. We<br>
need projects to take more ownership of their functional testing so that<br>
by the time we get to integration testing we're not exposing really<br>
fundamental bugs like being unable to handle 2 requests at the same time.<br>
<br>
For Kilo: I think we can and should be able to make progress on this on<br>
all integrated projects, as well as the python clients (which are<br>
basically untested.... and often very broken).<br>
<br></blockquote><div><br></div>Big +1 from me on this.<div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Consistency in southbound interfaces (Logging first)<br>
<br>
Logging and notifications are south bound interfaces from OpenStack<br>
providing information to people, or machines, about what is going on.<br>
There is also a 3rd proposed south bound with osprofiler.<br>
<br>
For Kilo: I think it's reasonable to complete the logging standards and<br>
implement them. I expect notifications (which haven't quite kicked off)<br>
are going to take 2 cycles.<br>
<br>
I'd honestly *really* love to see a unification path for all the the<br>
southbound parts, logging, osprofiler, notifications, because there is<br>
quite a bit of overlap in the instrumentation/annotation inside the main<br>
code for all of these.<br>
<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. API micro version path forward<br>
<br>
We have Cinder v2, Glance v2, Keystone v3. We've had them for a long<br>
time. When we started Juno cycle Nova used *none* of them. And with good<br>
reason, as the path forward was actually pretty bumpy. Nova has been<br>
trying to create a v3 for 3 cycles, and that effort collapsed under it's<br>
own weight. I think major API revisions in OpenStack are not actually<br>
possible any more, as there is too much intertia on existing interfaces.<br>
<br>
How to sanely and gradually evolve the OpenStack API is tremendously<br>
important, especially as a bunch of new projects are popping up that<br>
implement parts of it. We have the beginnings of a plan here in Nova,<br>
which now just needs a bunch of heavy lifting.<br>
<br>
For Kilo: A working microversion stack in at least one OpenStack<br>
service. Nova is probably closest, though Mark McClain wants to also<br>
take a spin on this in Neutron. I think if we could come up with a model<br>
that worked in both of those projects, we'd pick up some steam in making<br>
this long term approach across all of OpenStack.<br>
<br></blockquote><div>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. </div><div><br></div><div>Generally speaking the micro versioning will be much more maintainable than the current major API version methods. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Post merge testing<br>
<br>
As explained here -<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html</a><br>
we could probably get a lot more bang for our buck if we had a smaller #<br>
of integration configurations in the pre merge gate, and a much more<br>
expansive set of post merge jobs.<br>
<br>
For Kilo: I think this could be implemented, it probably needs more<br>
hands than it has right now.<br>
<br>
5. Consistent OpenStack python SDK / clients<br>
<br>
I think the client projects being inside the server programs has not<br>
served us well, especially as the # of servers has expanded. We as a<br>
project need to figure out how to get the SDK / unified client effort<br>
moving forward faster.<br>
<br>
For Kilo: I'm not sure how close to "done" we could take this, but this<br>
needs to become a larger overall push for the project as a whole, as I<br>
think our use exposed interface here is inhibiting adoption.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</blockquote><div><br></div><div>Cheers,</div><div>--Morgan </div></div>