[openstack-dev] [nova][oslo] Changes to oslo-incubator sync workflow

Roman Podoliaka rpodolyaka at mirantis.com
Thu Feb 20 10:14:05 UTC 2014


Hi all,

I'm ready to help with syncing of DB code. But we'll need reviewers
attention in both oslo-incubator in nova :)

Thanks,
Roman

On Thu, Feb 20, 2014 at 5:37 AM, Lance D Bragstad <ldbragst at us.ibm.com> wrote:
> Shed a little bit of light on Matt's comment about Keystone removing
> oslo-incubator code and the issues we hit. Comments below.
>
>
> Best Regards,
>
> Lance Bragstad
> ldbragst at us.ibm.com
>
> Doug Hellmann <doug.hellmann at dreamhost.com> wrote on 02/19/2014 09:00:29 PM:
>
>> From: Doug Hellmann <doug.hellmann at dreamhost.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>,
>> Date: 02/19/2014 09:12 PM
>> Subject: Re: [openstack-dev] [nova][oslo] Changes to oslo-incubator
>> sync workflow
>
>
>>
>>
>
>> On Wed, Feb 19, 2014 at 9:52 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>> As a side to this, as an exercise I tried a oslo sync in cinder to see
>> what kind of issues would arise and here are my findings so far:
>> https://review.openstack.org/#/c/74786/
>>
>> On Wed, Feb 19, 2014 at 6:20 PM, Matt Riedemann
>> <mriedem at linux.vnet.ibm.com> wrote:
>> >
>> >
>> > On 2/19/2014 7:13 PM, Joe Gordon wrote:
>> >>
>> >> Hi All,
>> >>
>> >> As many of you know most oslo-incubator code is wildly out of sync.
>> >> Assuming we consider it a good idea to sync up oslo-incubator code
>> >> before cutting Icehouse, then we have a problem.
>> >>
>> >> Today oslo-incubator code is synced in ad-hoc manor, resulting in
>> >> duplicated efforts and wildly out of date code. Part of the challenges
>> >> today are backwards incompatible changes and new oslo bugs. I expect
>> >> that once we get a single project to have an up to date oslo-incubator
>> >> copy it will make syncing a second project significantly easier. So
>> >> because I (hopefully) have some karma built up in nova, I would like
>> >> to volunteer nova to be the guinea pig.
>> >>
>> >>
>> >> To fix this I would like to propose starting an oslo-incubator/nova
>> >> sync team. They would be responsible for getting nova's oslo code up
>> >> to date.  I expect this work to involve:
>> >> * Reviewing lots of oslo sync patches
>> >> * Tracking the current sync patches
>> >> * Syncing over the low hanging fruit, modules that work without
>> >> changing
>> >> nova.
>> >> * Reporting bugs to oslo team
>> >> * Working with oslo team to figure out how to deal with backwards
>> >> incompatible changes
>> >>    * Update nova code or make oslo module backwards compatible
>> >> * Track all this
>> >> * Create a roadmap for other projects to follow (re: documentation)
>> >>
>> >> I am looking for volunteers to help with this effort, any takers?
>> >>
>> >>
>> >> best,
>> >> Joe Gordon
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> > Well I'll get the ball rolling...
>> >
>> > In the past when this has come up there is always a debate over should
>> > be
>> > just sync to sync because we should always be up to date, or is that
>> > dangerous and we should only sync when there is a need (which is what
>> > the
>> > review guidelines say now [1]).  There are pros and cons:
>> >
>> > pros:
>> >
>> > - we get bug fixes that we didn't know existed
>> > - it should be less painful to sync if we do it more often
>> >
>> > cons:
>> >
>> > - it's more review overhead and some crazy guy thinks we need a special
>> > team
>> > dedicated to reviewing those changes :)
>> > - there are some changes in o-i that would break nova; I'm specifically
>> > thinking of the oslo RequestContext which has domain support now (or
>> > some
>> > other keystone thingy) and nova has it's own RequestContext - so if we
>> > did
>> > sync that from o-i it would change nova's logging context and break on
>> > us
>> > since we didn't use oslo context.
>> >
>> > For that last con, I'd argue that we should move to the oslo
>> > RequestContext,
>> > I'm not sure why we aren't.  Would that module then not fall under
>> > low-hanging-fruit?
>
>> I am classifying low hanging fruit as anything that doesn't require
>> any nova changes to work.
>>
>> +1
>> > I think the DB API modules have been a concern for auto-syncing before
>> > too
>> > but I can't remember why now...something about possibly changing the
>> > behavior of how the nova migrations would work?  But if they are already
>> > using the common code, I don't see the issue.
>
>> AFAIK there is already a team working on db api syncing, so I was
>> thinking of let them deal with it.
>>
>> +1
>>
>> Doug
>>
>> >
>> > This is kind of an aside, but I'm kind of confused now about how the
>> > syncs
>> > work with things that fall under oslo.rootwrap or oslo.messaging, like
>> > this
>> > patch [2].  It doesn't completely match the o-i patch, i.e. it's not
>> > syncing
>> > over openstack/common/rootwrap/wrapper.py, and I'm assuming because
>> > that's
>> > in oslo.rootwrap now?  But then why does the code still exist in
>> > oslo-incubator?
>> >
>> > I think the keystone guys are running into a similar issue where they
>> > want
>> > to remove a bunch of now-dead messaging code from keystone but can't
>> > because
>> > there are still some things in oslo-incubator using oslo.messaging code,
>> > or
>> > something weird like that. So maybe those modules are considered out of
>> > scope for this effort until the o-r/o-m code is completely out of o-i?
>> >
>
> For the Keystone work specifically, we were looking to remove the
> openstack.common.notifier
> and openstack.common.rpc modules from Keystone common because we recently
> switched to
> oslo.messaging (since between those two modules it ends up being around
> 5,500 lines of dead code).
> We hit issues trying to remove notifier and rpc from Keystone because
> openstack.common.log_handler
> still imported notifier [1], and our docs failed to build [2][3]. We are
> trying to fix this
> by submitting a change to oslo.messaging that will graduate log_handler to
> oslo.messaging [4]. The
> patch is here [5] thanks to some help from Ben Nemec strengthening the test
> cases.
>
>
> [1]
> http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/log_handler.py#n19
> [2] https://review.openstack.org/#/c/73900/
> [3] https://review.openstack.org/#/c/73895/4
> [4] https://wiki.openstack.org/wiki/Oslo/GraduationStatus#oslo.messaging
> [5] https://review.openstack.org/#/c/74804/
>
>
>> > Finally, just like we'd like to have cores for each virt driver in nova
>> > and
>> > the neutron API in nova, I think this kind of thing, at least initially,
>> > would benefit from having some oslo cores involved in a team that are
>> > also
>> > familiar to a degree with nova, e.g. bnemec or dims.
>> >
>> > [1]
>> > https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist
>> > [2] https://review.openstack.org/#/c/73340/
>> >
>> > --
>> >
>> > Thanks,
>> >
>> > Matt Riedemann
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://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
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://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
>



More information about the OpenStack-dev mailing list