Open Stack

On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote:
> Hi, so shortly after the HOT migration landed, we hit
> https://bugs.launchpad.net/tripleo/+bug/1354305 which is that on even
> quite recently deployed clouds, the migrated templates were just too
> new. A partial revert (of just the list_join bit) fixes that, but a
> deeper problem emerged which is that stack-update to get from a
> non-HOT to HOT template appears broken
> (https://bugs.launchpad.net/heat/+bug/1354962).
> 
> I think we need to revert the HOT migration today, as forcing a
> scorched earth recreation of a cloud is not a great answer for folk
> that have deployed versions - its a backwards compat issue.
> 
> Its true that our release as of icehouse isn't  really useable, so we
> could try to wiggle our way past this one, but I think as the first
> real test of our new backwards compat policy, that that would be a
> mistake.

Hmmm. We blocked a good bit of changes to get these HOT templates in so
I hate to see us revert them. Also, It isn't clear to me how much work
it would be to fully support the non-HOT to HOT templates upgrade path.
How much work is this? And is that something we really want to spend
time on instead of all the other things?

Why not just create a branch of the old templates that works on the
existing underclouds? Users would then need to use these templates as a
one-time upgrade step to be able to upgrade to a heat HOT capable
undercloud first.

With regards to the seed...

Would a tool that allowed us to migrate the stateful data from an old
seed to a new seed be a better use of time here? A re-seeder might be a
useful tool to future proof upgrade paths that rely on the software
versions in the seed (Heat etc.) that aren't easily up-gradable.
Packages would help here too, but not everyone uses them...

Dan

> 
> What we need to be able to land it again, is some way whereby an
> existing cloud can upgrade their undercloud (via stack-update against
> the old heat deployed in the seed [today, old heat in the undercloud
> itself in future]) and then once that is deployed subsequent templates
> can use the new features. We're likely to run into such lockstep
> changes in future, so we also need to be able to recognise them in
> review / design, and call them out so we can fix them early rather
> than deep down the pike.
> 
> -Rob
>