Hi All, 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.
More detail on the discussions and action items are available in the summit etherpads[1]. 1. Convergence Phase-1 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: - Investigate memory issue w/ convergence and identify some quick gains. - Store outputs of stacks to avoid loading stacks for output retrieval and avoid making client calls for outputs. - Add heat job with stable tripleo templates(any large stack would probably do) and nova fake virt driver. - Test with python3(profile with tracemalloc) - Investigate possibility of using proton for RPC In addition to the above we would improve/add documentation for convergence with architecture and migration (from legacy to convergence) docs. 2. Convergence Phase-2 - Merge the remaining 'observe reality' patches - Add special flag for stack-update using get reality We may not be able to do more on convergence phase-2 (i.e continuous observer) in this cycle. 3. Rolling Upgrade As a community wide goal for this 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. - vhost change solution - DB triggers vs writing to multiple locations etc - Grenade job for rolling upgrade from stable to master 4. Validation Improvements We agreed that this work would mostly spill over to the next cycle. As a minimum we would write/freeze the spec on validation improvements (rename the validations, placeholder stuff, output schema etc) 5. API Versioning We would create specs on resource versioning and v2 API, before we discuss about supporting api micro versions in the later cycles. 6. Test Improvements and Defcore We agreed to use gabbi to write a new set of REST api tests in heat tree and then propose a subset of it to tempest for Defcore. 7. Heat Maturity 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. >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. Note: I may have missed some important action items that should be communicated here. Please feel free to add them as necessary. [1] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Heat Regards, Rabi Misra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
