Open Stack

On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 20/09/13 15:20 -0700, Monty Taylor wrote:
>
>> On 09/20/2013 02:55 PM, Ben Nemec wrote:
>>
>>> Not from a Gerrit perspective, but the Oslo policy is that a maintainer
>>> +1 on the code they maintain is the equivalent of a +2, so only one core
>>> is needed to approve.
>>>
>>> See https://github.com/openstack/**oslo-incubator/blob/master/**
>>> MAINTAINERS#L28<https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28>
>>>
>>
>> What if we rethought the organization just a little bit. Instead of
>> having oslo-incubator from which we copy code, and then oslo.* that we
>> consume as libraries, what if:
>>
>> - we split all oslo modules into their own repos from the start
>>
>
> IIRC, we're planning to have a design session around these lines at
> the summit. I think the only issue here is figuring out where some
> modules belong. For example, where would we put strutils? Should we
> have a single repo for it or perhaps have a more generic one, say
> oslo.text, were we could group strutils, jsonutils and some other
> modules?
>
> There are plenty of "single-file" packages out there but I'd
> personally prefer grouping modules as much as possible.
>

I agree.


>
> Another thing to consider is, what happens with Oslo modules depending
> on other oslo modules? I guess we would make sure all the dependencies
> are copied in the project as we do today but, when it comes to testing
> the single module, I think this could be an issue. For example,
> policy.py depends on fileutils, gettextutils and other oslo module
> which wouldn't fit in the same package, oslo.policy. This will make
> testing oslo.policy a real pain since we would have to "copy" its
> dependencies in its own tree as well.


This is a great reason to keep everything together in a single incubator
repository until a package is ready to stand on its own as a library.
Libraries can easily declare dependencies to be installed for testing, but
if we start copying bits of oslo around into separate git repositories then
we'll all go mad trying to keep all of the repos up to date. :-) In the
mean time, any review pain we have can be used as encouragement to bring
the library to a point where it can be moved out of the incubator.

It sounds like the primary concern is having enough keystone folks looking
at reviews of the policy code, without being overwhelmed by tracking all
Oslo changes. There are a couple of ways to address that.

The policy code seems very tightly associated with the keystone work.
There's no reason for Oslo to be the only program releasing reusable
libraries. We should consider having the Keystone team manage the policy
library in a repo they own. I'd love to have the Keystone middleware work
the same way, instead of being in the client repo, but one step at a time.

Of course, if the policy code is nearing the point where it is ready to
graduate from the incubator, then maybe that suggestion is moot and we
should just continue to push ahead on the path we're on now. We could have
people submitting policy code to oslo-incubator add "keystone-core" to
reviews (adding a group automatically adds its members), so they don't have
to subscribe to oslo notifications.

How close is the policy code to being ready to graduate?

Doug


>
>
>  - we make update.py a utility that groks copying from a directory that
>> contains a bunch of repos - so that a person wanting to use is might have:
>>  ~/src
>>  ~/src/oslo
>>  ~/src/oslo/oslo.db
>>  ~/src/oslo/oslo.policy
>>  and then when they run update.py ~/src/oslo ~/src/nova and get the
>> same results (the copying and name changing and whatnot)
>>
>
> If we split modules in its own repos, I'd rather use git submodules,
> which would then work better.


>
>
>> That way, we can add per-module additional core easily like we can for
>> released oslo modules (like hacking and pbr have now)
>>
>
> +1
>
>
>
>> Also, that would mean that moving from copying to releasing is more a
>> matter of just making a release than it is of doing the git magic to
>> split the repo out into a separate one and then adding the new repo to
>> gerrit.
>>
>>
> +1
>
>  Thoughts?
>>
>
> I like the idea overall, I'm a bit worried about how those modules
> would be organized.
>
> Any thoughts about the above concerns?
>
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20130923/a96cc21d/attachment.html>