<div dir="ltr"><div><div><div><div>Hi All,<br><br></div>We had number of very productive sessions at the summit last week. I thought it would be good to summarize them in ML thread, for us to be able to prioritize and work on them. As Ocata cycle is shorter than usual, we may not be able to finish lot of them.<br><br></div>More detail on the discussions and action items are available in the summit etherpads[1].<br><br></div>1. Convergence Phase-1<br><br></div>We all agreed that one of our top priorities this cycle would be make convergence engine perform at par, if not better than legacy. Though convergence is expected to perform better in a scaled out/distributed heat deployment, we would try to make it optimal for not distributed deployments like 'Tripleo undercloud'. Some of the action items to achieve this are as below: <div><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Investigate memory issue w/ convergence and identify some quick gains.</span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Store outputs of  stacks to avoid loading stacks for output retrieval and avoid making client calls for outputs.</span><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc"></span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Add heat job with stable tripleo templates(any large stack would probably do) and nova fake virt driver.</span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Test with python3(</span><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">profile with tracemalloc)</span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Investigate possibility of using proton for RPC</span></li></ul></div><div><br></div><div>In addition to the above we would improve/add documentation for convergence with architecture and migration (from legacy to convergence) docs.<br><br></div><div>2. Convergence Phase-2<br></div><div><ul><li>Merge the remaining 'observe reality' patches</li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Add special flag for stack-update using get reality</span></li></ul></div><div>We may not be able to do more on convergence phase-2 (i.e continuous observer) in this cycle.<br><br></div><div>3. Rolling Upgrade<br><br></div><div>As a community wide goal for th<span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc"></span>is cycle, rolling upgrade would be one of our priorities for Ocata cycle. This would involve testing out the different approaches we discussed in ML and during the summit. <span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc"></span><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc"><br><br></span><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">vhost change solution</span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">DB triggers vs writing to multiple locations etc</span></li></ul><ul><li><span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">Grenade job for rolling upgrade from stable to master</span></li></ul></div><div>4. Validation Improvements<span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc"></span><br><br></div><div>We agreed that this work would mostly spill over to the next cycle. As a minimum we would write/freeze the <span class="gmail-author-a-fbz84zvz65zz122zg5bz75zz84ztyz81zz89zc">spec on validation improvements (rename the validations, placeholder stuff, output schema etc)</span></div><div><br></div><div>5. API Versioning<br><br></div><div>We would create specs on resource versioning and v2 API, before we discuss about supporting api micro versions in the later cycles.<br></div><div><br></div><div>6. Test Improvements and Defcore<br><br>We agreed to use gabbi to write a new set of REST api tests in heat tree and then propose <br><div class="gmail_signature"><div dir="ltr"><div>a subset of it to tempest for Defcore.<br><br></div><div>7. Heat Maturity<br><br></div><div>Our discussion with the ops-tags-team was very productive. We seem to support 9 SDKs( 2 more than the 7 credited to us) and this has been corrected now.<br><br></div><div>From the user survey point of view (use of heat in production deployments), we probably are missing some score, as users of projects like magnum, sahara, murano, tacker in production may not be mentioning heat. After we send a mail confirming that, heat would be implicitly added by the survey team, when one of those projects  mentioned by the end user.<br><br></div><div><br></div><div>Note: I may have missed some important action items that should be communicated here. Please feel free to add them as necessary.  <br></div><div><br>[1] <a href="https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Heat">https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Heat</a><br><br>Regards,</div>Rabi Misra<div><br></div></div></div>
</div></div>