Open Stack

On 23/04/18 18:14, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100:
>> On 23/04/18 17:14, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
>>>> On 23/04/18 16:04, Doug Hellmann wrote:
>>>>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>>>>>> 7On 20/04/18 22:26, Doug Hellmann wrote:
>>>>>> <snip/>
>>>>>>> Without letting the conversation devolve too much into a discussion
>>>>>>> of Adjutant's case, please talk a little about how you would evaluate
>>>>>>> a project's application in general.  What sorts of things do you
>>>>>>> consider when deciding whether a project "aligns with the OpenStack
>>>>>>> Mission," for example?
>>>>>>>
>>>>>>> Doug
>>>>>>>
>>>>>>
>>>>>> For me, the most important thing for a project that wants to join is
>>>>>> that they act like "one of us" - what I think ttx refered to as "culture
>>>>>> fit".
>>>>>>
>>>>>> This is fairly wide ranging, but includes things like:
>>>>>>
>>>>>> * Do they use the PTIs[0]
>>>>>> * Do they use gerrit, or if they use something else, do they follow
>>>>>>   the same review styles and mechanisms?
>>>>>> * Are they on IRC?
>>>>>> * Do they use the mailing list for long running discussion?
>>>>>>   ** If a project doesn't have long running discussions and as a result
>>>>>>      does not have ML activity, I would see that as OK - my problem
>>>>>>      would be with a team that ran their own list.
>>>>>> * Do they use standard devstack / -infra jobs for testing?
>>>>>> * Do they use the standard common libraries (where appropriate)?
>>>>>>
>>>>>> If a project fails this test (and would have been accepted as something
>>>>>> that drives the mission), I see no issue with the TC trying to bring
>>>>>> them into the fold by helping them work like one of us, and accepting
>>>>>> them when they have shown that they are willing to change how they
>>>>>> do things.
>>>>>>
>>>>>> For the "product" fit, it is a lot more subjective. We used to have a
>>>>>> system (pre Big Tent) where the TC picked "winners" in a space and
>>>>>> blessed one project as the way to do $thing. Then, in big tent we
>>>>>> started to not pick winners, and allow anyone who was one of us, and
>>>>>> had a "cloud" application.
>>>>>>
>>>>>> Recently, we have moved back to seeing if a project overlaps with
>>>>>> another. The real test for this (from my viewpoint) is if the
>>>>>> perceived overlap is an area that the team that is currently in
>>>>>> OpenStack is interested in pursuing - if not we should default to
>>>>>> adding the project.
>>>>>
>>>>> We've always considered overlap to some degree, but it has come up
>>>>> more explicitly in a few recent discussions because of the nature
>>>>> of the projects.  Please see the other thread on this topic [1].
>>>>>
>>>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>>>>>
>>>>>> Personally, if the project adds something that we currently lack,
>>>>>> and have lacked for a long time (not to get too close to the current
>>>>>> discussion), or tries to reduce the amount of extra tooling that
>>>>>> deployers currently write in house, we should welcome them.
>>>>>>
>>>>>> The acid test for me is "How would I use this?" or "Have I written
>>>>>> tooling or worked somewhere that wrote tooling to do this?"
>>>>>>
>>>>>> If the answer is yes, it is a good indication that they fit with the
>>>>>> mission.
>>>>>
>>>>> This feels like the ideal open source approach, in which contributors
>>>>> are "scratching their own itch." How can we encourage more deployers
>>>>> and users of OpenStack to consider contributing their customization
>>>>> and integration projects? Should we?
>>>>
>>>> I think a lot of our major users are good citizens and are doing some or
>>>> all of this work in the open - we just have a discoverability issue.
>>>>
>>>> A lot of the benefit of joining the foundation as a project, is the
>>>> increased visibility gained from it, so that others who are deploying
>>>> OpenStack in a similar layout can find a project and use it.
>>>>
>>>> I think at the very least we should find a way to promote them (this
>>>> is where constellations could really help, as we could add non member
>>>> projects to constellations where they are appropriate.
>>>
>>> Do you foresee any issues with adding unofficial projects to the
>>> constellations?
>>>
>>> Doug
>>
>> No (from my viewpoint anyway) - I think they will be important to
>> include in any true collection of use cases - for example we definitely
>> will want to have a "PaaS" Constellation that includes things like
>> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
>> OpenStack works in the entire open source infrastructure community
>> and not just how it works internally - and showing how you can use other
>> open source software components *with* OpenStack is vital for that.
> 
> Would you make a distinction between things that have their own
> community like kubernetes, and things that might consider themselves
> on track to be part of the OpenStack community one day?
> 
> Doug

No - I would hope that one day they will just get a nice mascot image
on the constellation when they join the foundation, or a Strategic Focus
Area in the future.

Obviously, we should be conservative with the software we place on the
maps - we shouldn't add $THING days after it is first released / open
sourced, but if software is stable and solves a problem (or is actually
deployed in an environment) we should consider it, be it part of CNCF,
hosted on openstack infra, or somewhere else, as long as it aligns with
our principles, and our software.

At the risk of derailing this, a more interesting question would be
"Should we add something like Ceph to a constellation?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/3e48ea73/attachment.sig>