<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 2:17 AM, Alan Pevec <span dir="ltr"><<a href="mailto:apevec@gmail.com" target="_blank">apevec@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">2015-01-29 19:31 GMT+01:00 Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>>:<br>
> That means clients need overlapping dependencies with the stable branches.<br>
> I don't think this is a reasonable requirement, and am not sure what we gain from it.<br>
<br>
</span>Capping all Oslo and clients on stable/juno was reverted[1] due to<br>
issue with upgrades when you don't have overlap between master and<br>
previous release, has that been resolved?<br></blockquote><div><br></div><div>Non overlapping dependencies has been resolved as in grenade supports them.  </div><div><br></div><div>To quote Doug's commit message from the linked patch:</div><div><br></div><div>"<span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">Capping the requirements in the stable branch to a version lower than</span></div><span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">the minimum used in master means we can't do rolling updates any more. We
should undo the caps and fix problems when we encounter them (either by
fixing the libraries or by capping with some overlap to allow updates)."</span></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre"><br></span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre">By repining stable/juno we are saying we cannot upgrade a service without upgrading its python dependencies. If you are not using virtual environments this means you cannot upgrade half the services on the box, you must upgrade all or nothing. </span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre"><br></span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre">As for the 'fix the problems when we encounter them part,' this turns out to be a non-trivial burden on the development team (as opposed to the stable-maint team), due to grenade and branchless tempest.</span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre"><br></span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre">My understanding is this tradeoff has already been debated at one of the summits, and the agreed upon path going forward was to pin stable branches, just no one has done it yet.</span></font></div><div class="gmail_quote"><font color="#000000" face="monospace"><span style="white-space:pre"><br></span></font></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Alan<br>
<br>
[1] <a href="https://review.openstack.org/138546" target="_blank">https://review.openstack.org/138546</a><br>
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>