On Thu, Sep 4, 2014 at 12:39 PM, Tim Bell <tim.b...@cern.ch> wrote: > > -----Original Message----- > > From: Thierry Carrez [mailto:thie...@openstack.org] > > Sent: 04 September 2014 16:59 > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose > during > > the TC meeting > > > > Sean Dague wrote: > > > [...] > > > So, honestly, I'll probably remain -1 on the final integration vote, > > > not because Zaqar is bad, but because I'm feeling more firmly that for > > > OpenStack to not leave the small deployers behind we need to redefine > > > the tightly integrated piece of OpenStack to basically the Layer 1 & 2 > > > parts of my diagram, and consider the rest of the layers exciting > > > parts of our ecosystem that more advanced users may choose to deploy > > > to meet their needs. Smaller tent, big ecosystem, easier on ramp. > > > > > > I realize that largely means Zaqar would be caught up in a definition > > > discussion outside of it's control, and that's kind of unfortunate, as > > > Flavio and team have been doing a bang up job of late. But we need to > > > stop considering "integration" as the end game of all interesting > > > software in the OpenStack ecosystem, and I think it's better to have > > > that conversation sooner rather than later. > > > > I think it's pretty clear at this point that: > > > > (1) we need to have a discussion about layers (base nucleus, optional > extra > > services at the very least) and the level of support we grant to each -- > the > > current binary approach is not working very well > > > > (2) If we accept Zaqar next week, it's pretty clear it would not fall in > the base > > nucleus layer but more in an optional extra services layer, together > with at the > > very least Trove and Sahara > > > > There are two ways of doing this: follow Sean's approach and -1 > integration > > (and have zaqar apply to that "optional layer" when we create it), or +1 > > integration now (and have zaqar follow whichever other integrated > projects we > > place in that layer when we create it). > > > > I'm still hesitating on the best approach. I think they yield the same > end result, > > but the -1 approach seems to be a bit more unfair, since it would be > purely for > > reasons we don't (yet) apply to currently-integrated projects... > > > > 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. > > 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.
> Do you see the "optional layer" services being blessed / validated in some > way and therefore being easy to identify ? > > 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? 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. Anne 1. https://wiki.openstack.org/wiki/Documentation/IncubateIntegrate Tim > > -- > > Thierry Carrez (ttx) > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev