[openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Doug Hellmann doug at doughellmann.com
Mon May 23 15:41:40 UTC 2016


Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:
> On Fri, 20 May 2016, Thierry Carrez wrote:
> 
> > The other approach is product-centric: "lower-level pieces are OpenStack 
> > dependencies, rather than OpenStack itself". If we are missing a lower-level 
> > piece to achieve our mission and are developing it as a result, it could be 
> > developed on OpenStack infrastructure by members of the OpenStack community 
> > but it is not "OpenStack the product", it's an OpenStack *dependency*. It is 
> > not governed by the TC, it can use any language and tool deemed necessary.
> >
> > On this second approach, there is the obvious question of where "lower-level" 
> > starts, which as you explained above is not really clear-cut. A good litmus 
> > test for it could be whenever Python is not enough. If you can't develop it 
> > effectively with the language that is currently sufficient for the rest of 
> > OpenStack, then developing it as an OpenStack dependency in whatever language 
> > is appropriate might be the solution...
> 
> I don't think language does (or should) have anything to do with it.
> 
> The question is whether or not the tool (whether service or
> dependent library) is useful to and usable outside the openstack-stack.
> For example gnocchi is useful to openstack but you can use it with other
> stuff, therefore _not_ openstack. More controversially: swift can be
> usefully used all by its lonesome: _not_ openstack.

Add keystone, cinder, and ironic to that list.

> Not being in OpenStack (where "in" means "of the product") is good
> for OpenStack, good for the project and good for opensource in general:
> 
> * Outside the OpenStack bubble, looking in, one can see a bunch of
>    complexity and a bunch of bad architecture decisions but rarely
>    see the good stuff that is actually there, so it is easy enough to walk
>    away. Good stuff that a larger audience could benefit from may get
>    dismissed, if that good stuff has an opportunity to have an
>    independent identity, it can be useful.
> 
> * A project that is used by a larger and more diverse audience
>    (people-wise and technology-wise) will of necessity be more
>    robust.
> 
> * A project that defines itself as independent will be required to
>    have strong and narrow contracts to satisfy its diverse audiences.
> 
> * A project that has those strong and narrow contracts can use what
>    ever language it likes and still be useful and nobody really needs
>    to care all that deeply except for the people making it. If they
>    want to be in a language that infra doesn't want to support,
>    that's fine: there are plenty of other ways to do CI.
> 
> * An openstack which is more narrow is far easier for people to
>    comprehend and contemplate.
> 
> * A broad opensource world that has lots of nice things is a better
>    one.

As you say, there are a lot of good reasons to strive for loose
coupling between components. On the other hand, whether or not an
individual component can or should be used by itself isn't a
sufficient line when we're talking about the nature of OpenStack
as a whole, especially if we want interoperability between deployments.

Most of our services add value on top of some other existing project
(either by integrating them or abstracting them or both).  What
would that story look like if we said that because keystone can be
used by itself, it is not part of OpenStack? Would it make sense
to still require deployments that want to use the trademark to use
keystone for authentication?

Doug



More information about the OpenStack-dev mailing list