Open Stack

Hi all,

Here are some of my thoughts on the Austin summit sessions. Don't
hesitate to ask questions or fix my misunderstanding. I'll try to keep
it short, please also refer to the etherpads for more details
(sometimes :)):
https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Heat


Release model
----------------------

We'll continue to as usual in the cycle-with-milestones, and
investigate having a shorter feature freeze for more flexibility.


Default to convergence
---------------------------------

Now's the time to enable it by default. We have a bunch of small
things to fix in tests, but the main point is to check that projects
using Heat work fine. If we can pull it off I hope to do the switch by
newton-1, so in 3 weeks. That we'll leave us with plenty of time for
feedback and improvements


Convergence improvements
----------------------------------------

There are some changes that we can now make to use convergence, like
not polling on hooks, which would be nice. But the main part is to
work on performance, to close the gap with the legacy engine. There is
at least one issue with messaging that we need to investigate.


Performance
------------------

This is what I hope will be a focus for the cycle, especially with
regard to large stacks. We have one major issue with the way we handle
files in the environment, which clogs our memory usage. That fix is in
good progress, once merged we'll find some smaller things to
incrementally improve on. We need to measure more to be able detect
regressions early and test new approaches. I'll see with infra if we
can get a periodic job for that and how storage works.


Continuous observer
------------------------------

The outcome of that session was basically that we don't want to do
this in Heat, at least for the time being. First, we're missing the
notifications on the resources that we spawn. Until that functionality
exists in OpenStack, it'll be tough to write a generic solution. Then,
it's a policy driven mechanism, and you need to be able to customize
how to react to failure on resources. So for now we want to document
how you can use the current APIs outside of Heat to achieve this, and
make sure that it works fine.


HOT parser
-----------------

This was somewhat tricky subject, as we tried to mix external template
validation and template building. The former is difficult to pull off
without being wrong, duplicate efforts, or slowing down development
too much. It may be possible to do some basic validation, and we'll
see if we can create a reusable library for that. The latter is a bit
more clear (at least to me), and I hope something will be available
for Newton.


New heatclient commands
--------------------------------------

We listed improvements that can be made now that we completed the move
to OSC. I'm really interested on a way to get failures more easily, as
it's a common pattern and it'll improve user experience quite a bit.


Software deployment refinements
------------------------------------------------

We decided to add a new property on SoftwareConfig indicating the
inputs which creates a replacement. We also need to improve timeouts
management, and allow the ability to send data when deployments are in
progress to get debug information.


Using DLM
----------------

We managed to not talk about ZooKeeper too much :). We want to remove
the database locks that we have and use tooz instead. The key is to
provide a nice upgrade path, so starting with the locks use for
convergence seems easier. If it turns out to be painless, we'll move
the stack locks from the legacy engine as well.


Validation improvements
-----------------------------------

Many subjects were mentioned here, with regard to the HOT parser topic
as well. The change I'd like to see is using placeholder objects
everywhere instead of None, so that we can clarify validations of
non-resolved data.


Integration tests
-----------------------

Not much to say on that subject. We want to move to use tempest
plugin, and the tempest runner, and remove as much custom code that we
have as possible.


Thanks,

-- 
Thomas