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
is :)
Ian Cordasco wrote:
-----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