[openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"
harlowja at fastmail.com
Mon May 23 20:22:05 UTC 2016
Sean Dague wrote:
> On 05/23/2016 03:34 PM, Gregory Haynes wrote:
>> On Mon, May 23, 2016, at 11:48 AM, Doug Hellmann wrote:
>>> Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100:
>>>> On Mon, 23 May 2016, Doug Hellmann wrote:
>>>>> Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:
>>>>>> 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.
>> Making a tool which is useful outside of the OpenStack context just
>> seems like good software engineering - it seems odd that we would try
>> and ensure our tools do not fit this description. Fortunately, many (or
>> even most) of the tools we create *are* useful outside of the OpenStack
>> world - pbr, git-review, diskimage-builder, (I hope) many of the oslo
>> libraries. This is really a question of defining useful interfaces more
>> than anything else, not a statement of whether a tool is part of our
> Only if you are willing to pay the complexity and debt cost of having
> optional backends all over the place.
We seem to do this quite well even without building tools/projects that
work outside of openstack ;)
Or are you saying that using such library/project(s) u have to accept
that there will be many optional backends that you will likely not/never
use that exist in said library/project (and thus are akin to dead weight)?
> For instance, I think we're well beyond that point that Keystone being
> optional should be a thing anywhere (and it is a thing in a number of
> places). Keystone should be our auth system, all projects 100% depend on
> it, and if you have different site needs, put that into a Keystone backend.
> Most of the oslo libraries require other oslo libraries, which is fine.
> They aren't trying to solve the general purpose case of logging or
> configuration or db access. They are trying to solve a specific set of
> patterns that are applicable to OpenStack projects.
I just took a quick stab at annotating which ones (I think are) useable
outside of openstack (without say bringing in the configuration
ideology/pattern that oslo.config adds) and made the following:
So out of 33 that's about half (~17) that I think are useable outside
without to many patterns/ideologies being forced on non-openstack folks
(if your external project accepts the pattern of oslo.config then the
More information about the OpenStack-dev