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