[openstack-dev] [ALL] Removing generate_uuid() from uuidutils

Clint Byrum clint at fewbar.com
Thu Nov 14 03:26:17 UTC 2013


Excerpts from Michael Still's message of 2013-11-13 13:24:52 -0800:
> On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <eric at cloudscaling.com> wrote:
> 
> > I don't think it is a problem to remove the code in oslo first, as
> > long as no other oslo-incubator code uses it. Projects don't have to
> > sync the code and could always revert should that they do.
> 
> I strongly disagree. It stops projects from syncing with oslo until
> they go through the code churn to remove the method.
> 
> > However, like Mark, I'm inclined to consider the value of
> > is_uuid_like. While undoubtedly useful, is one method sufficient to
> > warrant creating a new top-level module. Waiting for it to hit the
> > standard library will take quite a long time...
> >
> > There are other components of oslo that are terse and questionable as
> > standalone libraries. For these, it might make sense to aggressively
> > consider rolling some modules together?
> >
> > One clear example would be log.py and log_handler.py, another would be
> > periodic_task.py and loopingcall.py
> 
> I'm not sure I see the harm in leaving small but widely used modules
> in oslo incubator. If we really want to release everything as a
> library, can't we just have a generic catchall one for the small
> things? oslo.therest perhaps?

It seems to me that we have two different encodetures in oslo:

1) Useful reusable code. config, logging, db access, etc.
2) Common OpenStack conventions/formats/etc.

Our usage of this module is just a level of indirection for all of us
to share. I don't mind having a tiny library that makes things more
consistent.

I suggest that if something is found to be a common OpenStack convention,
it can go in a library that we call something clever, like "kevin", or
"oslo.common".



More information about the OpenStack-dev mailing list