Open Stack

On 09/05/2014 05:27 AM, Thierry Carrez wrote:
> 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.

(This is definitely drifting, sorry to the zaqar team for that)

Honestly, I really think the TC needs to get out of the gold star
granting business for the larger ecosystem. It's going to be hard enough
to keep focus and attention on a small nucleus, and I think that has to
be the primary responsibility of the group.

When I say big ecosystem, I mean *big*. I think the goal is 100s of
production ready projects in the ecosystem. All solving interesting
problems, all adding value to the whole.

I think realistically a self certification process that would have
artifacts in a discoverable place. I was thinking something along the
lines of a baseball card interface with a short description of the
project, a list of the requirements to deploy (native and python), a
link the the API docs, a link to current test coverage, as well as some
statement on the frequency of testing, stats on open bugs and current
trending and review backlog, current user testimonials. Basically the
kind of first stage analysis that a deployer would do before pushing
this out to their users.

	-Sean

-- 
Sean Dague
http://dague.net