<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 12:39 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> -----Original Message-----<br>
> From: Thierry Carrez [mailto:<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>]<br>
> Sent: 04 September 2014 16:59<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during<br>
> the TC meeting<br>
><br>
> Sean Dague wrote:<br>
> > [...]<br>
> > So, honestly, I'll probably remain -1 on the final integration vote,<br>
> > not because Zaqar is bad, but because I'm feeling more firmly that for<br>
> > OpenStack to not leave the small deployers behind we need to redefine<br>
> > the tightly integrated piece of OpenStack to basically the Layer 1 & 2<br>
> > parts of my diagram, and consider the rest of the layers exciting<br>
> > parts of our ecosystem that more advanced users may choose to deploy<br>
> > to meet their needs. Smaller tent, big ecosystem, easier on ramp.<br>
> ><br>
> > I realize that largely means Zaqar would be caught up in a definition<br>
> > discussion outside of it's control, and that's kind of unfortunate, as<br>
> > Flavio and team have been doing a bang up job of late. But we need to<br>
> > stop considering "integration" as the end game of all interesting<br>
> > software in the OpenStack ecosystem, and I think it's better to have<br>
> > that conversation sooner rather than later.<br>
><br>
> I think it's pretty clear at this point that:<br>
><br>
> (1) we need to have a discussion about layers (base nucleus, optional extra<br>
> services at the very least) and the level of support we grant to each -- the<br>
> current binary approach is not working very well<br>
><br>
> (2) If we accept Zaqar next week, it's pretty clear it would not fall in the base<br>
> nucleus layer but more in an optional extra services layer, together with at the<br>
> very least Trove and Sahara<br>
><br>
> There are two ways of doing this: follow Sean's approach and -1 integration<br>
> (and have zaqar apply to that "optional layer" when we create it), or +1<br>
> integration now (and have zaqar follow whichever other integrated projects we<br>
> place in that layer when we create it).<br>
><br>
> I'm still hesitating on the best approach. I think they yield the same end result,<br>
> but the -1 approach seems to be a bit more unfair, since it would be purely for<br>
> reasons we don't (yet) apply to currently-integrated projects...<br>
><br>
<br>
</div></div>The one concern I have with a small core is that there is not an easy way to assess the maturity of a project on stackforge. The stackforge projects may be missing packaging, Red Hat testing, puppet modules, install/admin documentation etc. Thus, I need to have some indication that a project is deployable before looking at it with my user community to see if it meets a need that is sustainable.<br>
<br></blockquote><div><br></div><div>I identify with this concern as Docs PTL. That said, it's very difficult already even if a project is under the "openstack" github org to know how well documented it is. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Do you see the "optional layer" services being blessed / validated in some way and therefore being easy to identify ?<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>I've already started to work on doc requirements for incubating and integrating projects [1], which may help with some checklist creation. My thinking is, if you can't document it, it's not well-validated. Is that reasonable, to adopt a "docs or it didn't happen" stance here? </div>
<div><br></div><div>Thanks for thinking on this -- I do like the layers approach and I think we just need to define expectations for layers so all the community can do a quick sanity check.</div><div>Anne</div><div> </div>
<div>1. <a href="https://wiki.openstack.org/wiki/Documentation/IncubateIntegrate">https://wiki.openstack.org/wiki/Documentation/IncubateIntegrate</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">
Tim<br>
</font></span><div class=""><div class="h5">> --<br>
> Thierry Carrez (ttx)<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>