[openstack-dev] [oslo] Split Oslo Incubator?

Doug Hellmann doug.hellmann at dreamhost.com
Tue Apr 8 14:05:31 UTC 2014


On Tue, Apr 8, 2014 at 6:35 AM, Victor Stinner
<victor.stinner at enovance.com> wrote:
> (Follow-up of the "[olso] use of the "oslo" namespace package" thread)
>
> Hi,
>
> The openstack.common module also known as "Oslo Incubator" or "OpenStack
> Common Libraries" has 44 dependencies. IMO we reach a point where it became
> too huge. Would it be possible to split it into smaller parts and distribute
> it on PyPI with a stable API? I don't know Olso Incubator enough to suggest
> the best granularity. A hint can be the number of dependencies.

Yes, as others have pointed out we will be doing this in Juno. See
https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans

>
> Sharing code is a good idea, but now we have SQLAchmey, WSGI, cryptographic,
> RPC, etc. in the same module. Who needs all these features at once? Olso
> Incubator must be usable outside OpenStack.

While I agree that we should be thinking about code reuse outside of
OpenStack, it is perfectly OK to discover that we have a module other
OpenStack projects want to use but that won't (or shouldn't) be used
by anyone else.

>
>
> Currently, Oslo Incubator is installed and updated manually using a
> "update.sh" script which copy ".py" files and replace "openstack.common" with
> "nova.openstack.common" (where nova is the name of the project where Oslo
> Incubator is installed).
>
> I guess that update.sh was written to solve the two following points, tell me
> if I'm wrong:
>
>  - unstable API: the code changes too often, whereas users don't want to
> update their code regulary. Nova has maybe an old version of Olso Incubator
> because of that.
>
>  - only copy a few files to avoid a lot of dependencies and copy useless files
>
> Smaller modules should solve these issues. They should be used as module:
> installed system-wide, not copied in each project. So fixing a bug would only
> require a single change, without having to "synchronize" each project.
>
>
> Yesterday, I proposed to add a new time_monotonic() function to the timeutils
> module. We asked me to enhance existing modules (like Monotime).
>
> We should now maybe move code from Oslo Incubator to "upstream" projects. For
> example, timeutils extends the iso8601 module. We should maybe contribute to
> this project and replace usage of timeutils with directy call to iso8601?

That may make sense for your new function. I think there are some
other things in timeutils that don't make sense to upstream. The
isotime() and parse_isotime() functions are relatively simple wrappers
around existing functions that give us consistent timestamps across
projects, for example. Those are useful to us as OpenStack developers,
but I'm not sure they're useful to anyone else as written.

Doug

>
> Victor
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list