Open Stack

On Wed, Nov 13, 2013 at 4:20 PM, Eric Windisch <eric at cloudscaling.com>wrote:

> >> Each project should directly use the standard uuid module or implement
> its
> >> own helper function to generate uuids if this patch gets in.
> >>
> >> Any thoughts on this change? Thanks.
> >
> >
> > Unfortunately it looks like that change went through before I caught up
> on
> > email. Shouldn't we have removed its use in the downstream projects (at
> > least integrated projects) before removing it from Oslo?
>
> 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.
>

Well, I wanted to avoid having projects decide that merging Oslo code was a
hassle or risky, because that breaks the promise of the project. We talked
at the summit about providing patches to consuming projects when we break
Oslo APIs, and I think that's a reasonable approach. When we do break an
API, we want to ensure that we at least have a plan for how consumers could
be updated. WIP patches for the consumers show that we've thought through
the changes sufficiently to at least continue to cover our existing use
cases.


>
> 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 like having the modules separate, and don't think each top-level module
implies a standalone library after graduation. For example, there are some
other modules related to string formatting that we could combine into an
oslo.text library, when they are ready to graduate.

Doug


>
> --
> Regards,
> Eric Windisch
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/df7b016f/attachment.html>