[openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"
harlowja at fastmail.com
Tue May 24 19:00:15 UTC 2016
Ok, probably should be chopped out of the oslo lib list then ;)
I'll do that, since it seems to be really not the right name for what it
Ian Cordasco wrote:
> -----Original Message-----
> From: Joshua Harlow<harlowja at fastmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions)<openstack-dev at lists.openstack.org>
> Date: May 23, 2016 at 15:23:32
> To: OpenStack Development Mailing List (not for usage questions)<openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"
>> 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:
>> automaton (useable)
>> cliff (useable)
>> cookiecutter (useable)
> I'm catching up on this thread, but cookiecutter most certainly is *NOT* an OpenStack project: https://pypi.io/project/cookiecutter/
> It was createdy by Audrey Roy Greenfeld.
>> debtcollector (useable)
>> futurist (useable)
>> osprofiler (useable?)
>> oslo.policy (useable?)
>> oslo.privsep (useable?)
>> oslo.serialization (useable)
>> oslotest (useable)
>> oslo.utils (useable)
>> 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).
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Ian Cordasco
More information about the OpenStack-dev