-----Original Message----- From: Joshua Harlow <harlo...@fastmail.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: May 23, 2016 at 15:23:32 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Ian Cordasco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
