Open Stack

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
>> community.
>
> 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:

automaton (useable)
cliff (useable)
cookiecutter (useable)
debtcollector (useable)
futurist (useable)
osprofiler (useable?)
oslo.cache
oslo.concurrency
oslo.context
oslo.config
oslo-cookiecutter
oslo.db
oslo.i18n
oslo.log
oslo.messaging
oslo.middleware
oslo.policy (useable?)
oslo.privsep (useable?)
oslo.reports
oslo.rootwrap
oslo.serialization (useable)
oslo.service
oslosphinx
oslotest (useable)
oslo.utils (useable)
oslo.versionedobjects
oslo.vmware
hacking (useable)
pbr (useable)
pyCADF (useable?)
stevedore (useable)
taskflow (useable)
tooz (useable)

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 
number increases).

>
> 	-Sean
>