[openstack-dev] [heat]Policy on upgades required config changes
sean at dague.net
Tue Mar 11 11:04:32 UTC 2014
On 03/04/2014 12:39 PM, Steven Hardy wrote:
> Hi all,
> As some of you know, I've been working on the instance-users blueprint.
> This blueprint implementation requires three new items to be added to the
> heat.conf, or some resources (those which create keystone users) will not
> So on upgrade, the deployer must create a keystone domain and domain-admin
> user, add the details to heat.conf, as already been done in devstack.
> The changes requried for this to work have already landed in devstack, but
> it was discussed to day and Clint suggested this may be unacceptable
> upgrade behavior - I'm not sure so looking for guidance/comments.
> My plan was/is:
> - Make devstack work
> - Talk to tripleo folks to assist in any transition (what prompted this
> - Document the upgrade requirements in the Icehouse release notes so the
> wider community can upgrade from Havana.
> - Try to give a heads-up to those maintaining downstream heat deployment
> tools (e.g stackforge/puppet-heat) that some tweaks will be required for
> However some have suggested there may be an openstack-wide policy which
> requires peoples old config files to continue working indefinitely on
> upgrade between versions - is this right? If so where is it documented?
This is basically enforced in code in grenade, the language for this
actually got lost in the project requirements discussion in the TC, I'll
bring that back in the post graduation requirements discussion we're
The issue is - Heat still doesn't materially participate in grenade.
Heat is substantially far behind the other integrated projects in it's
integration with the upstream testing. Only monday did we finally start
gating on a real unit of work for Heat (the heat-slow jobs). If I was
letter grading projects right now on upstream testing I'd give Nova an
A, Neutron a C (still no full run, no working grenade), and Heat a D.
So in short. Heat did the wrong thing. You should be able to use your
configs from the last release. This is what all the mature projects in
OpenStack do. In the event that you *have* to make a change like that it
requires an UpgradeImpact tag in the commit. And those should be limited
really aggressively. This is the whole point of the deprecation cycle.
Samsung Research America
sean at dague.net / sean.dague at samsung.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev