Open Stack

Tim Bell wrote:
>> -----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 ?

Yes, I think whatever exact shape this takes, it should convey some
assertion of stability to be able to distinguish itself from random
projects. Some way of saying "this is good and mature, even if it's not
in the inner circle".

Being in The "integrated release" has been seen as a sign of stability
forever, while it was only ensuring "integration" with other projects
and OpenStack processes. We are getting better at requiring "maturity"
there, but if we set up layers, we'll have to get even better at that.

-- 
Thierry Carrez (ttx)