Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161102/4606e15e/attachment-0001.html>