Open Stack

On 23/04/18 14:50, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
> 
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
> 
> Where do you draw the line at "gratuitous"?

Does the project basically promise "$OTHER_PROJECT but better"?
For example, for me, if a project re-created another projects API - I
would call that gratuitous.

> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?

It depends on the context - for example with deployment tooling,
companies may have pre existing DC orchestration tools, and having
and OpenStack deployment tool in $CONFIGMGMT can help people run
quicker.

Having 2 image stores, not so much, as there is then confusion about
what tool to deploy, or deploy both, and any issues may need to have 2
different solutions, or at least 2 patches.

There may be circumstances where 2 tools make sense (e.g. Messaging as a
Service did have 2 projects, but they served 2 different use cases, so
it made sense)

> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?

For deployment tooling - having the one true way to deploy OpenStack
would have made a lot of the work I have done in the last 4 or 5 years
redundant :) - We would probably be using bash scripts, but not having
people re-create the flow of installing OpenStack in $CFGMGMT_TOOL
de-jour in OpenStack may have focused resource. Or just forced
deployment teams out of OpenStack to somewhere else.

OS packing is definitely a good thing for duplication.

I don't think we have many service project areas that we have
duplication that would not have failed some of the stricter "culture
fit" discussions we have now had in the post Big Tent OpenStack.

We would have probably blocked things like Octavia (as Neutron LBaaS
existed), Designate (as Nova DNS was a thing back then), Monasca,
Neutron itself (as Nova Network was a thing).

> Doug
> 
> [1] https://governance.openstack.org/tc/reference/new-projects-requirements.html
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-------------- 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/c0ef9ce3/attachment.sig>