<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 9:20 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 2/19/2014 7:13 PM, Joe Gordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 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>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br></div></div>
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 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:<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 dedicated to reviewing those changes :)<br>
- 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.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Another con is that if we do find a critical bug in an incubator module, and a project that uses that module is far out of date, applying the fix may be more difficult. (This is also another motivation for moving code out of the incubator entirely, but as Joe pointed out earlier today, that's not really a short-term solution.)</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br>
<br>
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.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">There has been some recent work on the db code to make it more suitable for use in some of the other projects that don't have a single global session pool. There's a compatibility shim, which should make the update painless, but it's not just a simple file copy.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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/<u></u>wrapper.py, and I'm assuming because that's in oslo.rootwrap now? But then why does the code still exist in oslo-incubator?<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">After a module graduates to a library, we treat the incubator copy as the "stable branch" until all of the integrated projects that consume the module have migrated to the new library. That way if bugs are found, the fixes can be applied to a project without having to also migrate to the library.</div>
</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, the best action is to port to the library. As a fall back, at least update to the most current version from in the incubator now. I believe all projects are already updated to use oslo.rootwrap.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">There's a notifier middleware that uses the RPC code from the incubator still. I believe work on moving that module into oslo.messaging has started, although that's based on conversations from earlier today so it might not be very far along yet. :-)</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">+1, and FWIW, Russell and Mark are also Oslo cores.</div><br></div><div><div class="gmail_default" style="font-size:small">Doug</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist" target="_blank">https://wiki.openstack.org/<u></u>wiki/ReviewChecklist#Oslo_<u></u>Syncing_Checklist</a><br>
[2] <a href="https://review.openstack.org/#/c/73340/" target="_blank">https://review.openstack.org/#<u></u>/c/73340/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>