Open Stack

On Mon, Sep 23, 2013 at 9:56 PM, Adam Young <ayoung at redhat.com> wrote:

>  On 09/23/2013 03:21 PM, Doug Hellmann wrote:
>
>
>
>
> 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
>>>>
>>>
>>> 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?
>
>
> I would argue that it should graduate now.  Keystone is willing to take it
> on as a subproject, just like  the keystoneclient code is.  We discussed
> putting it in keystoneclient, since auth_token middleware is there
> already.   Thus, anything already using auth_token middleware already has
> the package.
>

I like that in general, although I'd rather see it in a separate repository
than piled into the client -- unless there's a connection between the
policy code and the client code that I just don't understand?

Doug


>
>
>
>
>
>  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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20130924/be0229ee/attachment.html>