On 12 August 2014 07:24, Dan Prince <dpri...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
