Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/5c1b38ea/attachment.html>