> -----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. Do you see the "optional layer" services being blessed / validated in some way and therefore being easy to identify ? 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
