<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:52 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/" target="_blank">https://review.openstack.org/#/c/74786/</a><br>
<div class=""><br>
On Wed, Feb 19, 2014 at 6:20 PM, Matt Riedemann<br>
<<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
><br>
><br>
</div><div><div class="h5">> 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>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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>
<br>
</div></div>I am classifying low hanging fruit as anything that doesn't require<br>
any nova changes to work.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">> 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>
<br>
</div>AFAIK there is already a team working on db api syncing, so I was<br>
thinking of let them deal with it.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Doug</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><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>
><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" target="_blank">https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist</a><br>
> [2] <a href="https://review.openstack.org/#/c/73340/" target="_blank">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>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>