Open Stack

Now getting very Heat-specific. W.r.t. to
https://review.openstack.org/#/c/303692/ , the goal is to de-duplicate
raw_template.files (this is a dict of template filename to contents),
both in the DB and in RAM. The approach this patch is taking is that,
when one template is created by reference to another, we just re-use the
original template's files (ultimately in a new table,
raw_template_files). In the case of nested stacks, this saves on quite a
bit of duplication.

If we follow the 3-step pattern discussed earlier in this thread, we
would be looking at P release as to when we start seeing DB storage
improvements. As far as RAM is concerned, we would see improvement in
the O release since that is when we would start reading from the new
column location (and could cache the template files object by its ID).
It also means that for the N release, we wouldn't see any RAM or DB
improvements, we'll just start writing template files to the new
location (in addition to the old location). Is this acceptable, or do
impose some sort of downtime restrictions on the next Heat upgrade?

A compromise could be to introduce a little bit of downtime:

For the N release:
 1. Add the new column (no need to shut down heat-engine).
 2. Shut down all heat-engine's.
 3. Upgrade code base to N throughout cluster.
 4. Start all heat engine's. Read from new and old template files
locations, but only write to the new one.

For the O release, we could perform a rolling upgrade with no downtime
where we are only reading and writing to the new location, and then drop
the old column as a post-upgrade migration (i.e, the typical N+2 pattern
[1] that Michal referenced earlier and I'm re-referencing :-).

The advantage to the compromise is we would immediately start seeing RAM
and DB improvements with the N-release.

[1]
http://docs.openstack.org/developer/cinder/devref/rolling.upgrades.html#database-schema-and-data-migrations