> -----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 

Do you see the "optional layer" services being blessed / validated in some way 
and therefore being easy to identify ?

> --
> 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

Reply via email to