Open Stack

-----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
> >> 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)

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.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
> >
>  
> __________________________________________________________________________  
> 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
>  

--  
Ian Cordasco