
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 10, 2015, at 6:00 PM, Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com" class="">devananda.vdv@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote">On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell <<a href="mailto:lauren@openstack.org" class="">lauren@openstack.org</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

- Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence.<br class=""></blockquote><div class=""><br class=""></div><div class="">We're not lowering the testing standards of existing projects... can you be more clear as to what is creating this concern?</div></div></div></div></blockquote><div><br class=""></div><div>The concern they raised was not necessarily about a testing standard for any individual project, but more about the combination of testing across that set of the most commonly deployed projects. In other words, if there is no “kernel” grouping, it potentially makes it harder to understand the full set of dependencies, how well the integration between nova and glance is tested, and things along those lines. One item that came up that a lot of them seemed to appreciate, for example, was that there was some forcing function for the integrated projects that kept their dependencies somewhat aligned and allowed them to understand what all they might need to be running to deploy any set of those projects. If the projects are all split apart, now they would have to deal with understanding that separately for each project they intend to deploy. Sean had mentioned in the session that some of this was probably already going to be changing, but I do think it was an interesting point that seemed to be very widely held among the operators there.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

For tags, I think defining a set of projects based on a broad reference architecture / use case like "base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, "compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects.<br class="">

<br class=""></blockquote><div class=""><br class=""></div><div class="">I've started drafting some tags for "layers" or "use cases" -- I'm sure they'll get expanded on. I'll post a link once I've uploaded to gerrit.</div></div></div></blockquote><div><br class=""></div><div>That’s great news. I think defining those important tags will go a long way in giving people confidence in the process and moving forward. </div><div><br class=""></div><div>I believe this is the one you started: <a href="https://review.openstack.org/#/c/163236/" class="">https://review.openstack.org/#/c/163236/</a></div><div><br class=""></div><div>Might be worth sharing over to the operators mailing list where Subbu has a message about some of the discussions as well: <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html" class="">http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html</a></div></div><div class=""><br class=""></div><div class=""><div class="">I’m sorry it took me a while to respond to this. Thanks for taking time to provide feedback last week.</div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></div></body></html>