<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 June 2014 16:27, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.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"><div dir="ltr"><div style="margin-left:40px">1. We need strict EOS and EOL rules to decide how many maintenance releases there will be for each series or our QA team and infrastructure will not ever be available to digest it.<br>
</div></div></blockquote><div><br></div><div>Agreed. Would it not be prudent to keep with the OpenStack support standard - support latest version and the -1 version?</div><div> </div><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">
<div dir="ltr"><div style="margin-left:40px">
</div><div style="margin-left:40px">3. We need to clearly specify the restrictions which patching and upgrade process we support:<br></div><div style="margin-left:40px"><div style="margin-left:40px">a. New environments can only be deployed with the latest version of OpenStack and FUEL Library supported<br>

</div></div><div style="margin-left:40px"><div style="margin-left:40px">b. Old environments can only be updated within the only minor release (e.g. 5.0.1->5.0.2 is allowed, 5.0.1->5.1 is not)<br></div></div></div></blockquote>
<div><br></div><div>Assuming that the major upgrades will be handled in <a href="https://blueprints.launchpad.net/fuel/+spec/upgrade-major-openstack-environment">https://blueprints.launchpad.net/fuel/+spec/upgrade-major-openstack-environment</a> then I agree. If not, then we have a sticking point here. I would agree that this is a good start, but in the medium to long term it is important to be able to upgrade from perhaps the latest minor version of the platform to the next available major version.</div>
<div> </div><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"><div dir="ltr"><div style="margin-left:40px"><div style="margin-left:40px">
</div></div><div style="margin-left:40px">
4. We have some devops tasks we need to finish to feel more comfortable in the future to make testing of patching much easier:<br></div><div style="margin-left:40px"><div style="margin-left:40px">a. we need to finish devops bare metal and distributed enviroments setup to make CI and testing process easier<br>

</div></div><div style="margin-left:40px"><div style="margin-left:40px">b. we need to implement elastic-recheck like feature to analyze our CI results in order to allow developers to retrigger checks in case of floating bugs<br>

</div></div><div style="margin-left:40px"><div style="margin-left:40px">c. we need to start using more sophisticated scheduler</div></div></div></blockquote><div><br></div><div>I find the scheduler statement a curiosity. Can you elaborate?</div>
</div></div></div>