Open Stack

On 12 August 2014 07:24, Dan Prince <dprince at redhat.com> wrote:
> 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?

Following up with Heat folk, apparently the non-HOT->HOTness was a
distraction - I'll validate this on the hp1 region asap, since I too
would rather not revert stuff.

We may need to document a two-step upgrade process for the UC - step 1
upgrade the UC image, *same* template, step 2, use new template to get
new functionality.

> 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.

We could. But since we compile things, we could just keep a copy of
the last deployed-with-template.

> 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...

The plan we discussed at the midcycle to use a real stateful partition
for the seed will do this I think.

-Rob
-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud