Open Stack

> -----Original Message-----
> From: Thierry Carrez [mailto:thierry at openstack.org]
> Sent: 04 September 2014 16:59
> To: openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev