[openstack-dev] Osl and dangerous code merging

Adam Young ayoung at redhat.com
Thu Aug 8 23:01:23 UTC 2013


On 08/08/2013 07:05 AM, Mark McLoughlin wrote:
> On Thu, 2013-08-08 at 11:49 +0100, Daniel P. Berrange wrote:
>> On Thu, Aug 08, 2013 at 11:39:44AM +0100, Mark McLoughlin wrote:
>>> What do you mean by "dangerous code merging" in the subject? The body of
>>> your mail doesn't make any reference to whatever "danger" you're seeing.
>>>
>>> On Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote:
>>>> Hi All,
>>>>
>>>> Could somebody answer me, why we are merging oslo code in other projects
>>>> and don't use
>>>> git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)
>>> The idea of using submodules has come a few times. I don't have a
>>> fundamental objection to it, except any time I've seen submodules used
>>> in a project they've been extremely painful for everyone involved.
>>>
>>> I'd be happy to look at a demo of a submodule based system for projects
>>> to use code from oslo-incubator.
>> submodules certainly could work as a way to avoid the cut+paste
>> approach we currently do. I agree though that they do add an
>> extra layer of pain & suffering for developers who don't fully
>> understand what they're doing. We use them in libvirt and try
>> to hide the pain behind clever scripts which attempt to keep
>> the submodule properly synced, but we still get pretty frequent
>> problem reports from devs who've managed to get themselves into
>> a mess with the submodule state.
> Yes, libvirt forms part of my negative experience of submodules :)
>
>> If we want to improve our interaction with oslo then IMHO more
>> effort should be spent on turning bits of oslo-incubator into
>> stable, standalone modules, removing the cut+paste need entirely.
> Totally. Code is not intended to live in oslo-incubator forever and
> we're having increasing success in moving stuff out:
>
> https://wiki.openstack.org/wiki/Oslo#Libraries

Keystone has, I think, validated the set of oslo libraries that it 
uses:  gettext, jsontutils, importutils, crypto, and policy.

gettext and jsontutils I'd be OK with these in the same library, but 
split is fine. I think  we sync down gettext and jsontutils, more often 
than any others.

Should importutils stand alone?  Seems reasonable.

Crypto is a pretty strong contender as well.  I think it might make 
sense to move it to a single file instead of a subdir.

Would it be possible for Keystone core to be considered the maintaners 
of oslo.policy?  We seem to have the most people focused on RBAC and 
policy enforcement, and it seems to be a natural fit. Policy was 
origianlly under Keystone.

We should also have an auth library.  I could see huge pieces of 
python-keystone client ending up in there.  Again, this would probably 
be best owned by the Keystone team, at least to start.

>
> Cheers,
> Mark.
>
>
> _______________________________________________
> 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