[openstack-dev] [heat]Policy on upgades required config changes
Clint Byrum
clint at fewbar.com
Tue Mar 4 22:06:16 UTC 2014
Excerpts from Steven Hardy's message of 2014-03-04 09:39:21 -0800:
> Hi all,
>
> As some of you know, I've been working on the instance-users blueprint[1].
>
> This blueprint implementation requires three new items to be added to the
> heat.conf, or some resources (those which create keystone users) will not
> work:
>
> https://review.openstack.org/#/c/73978/
> https://review.openstack.org/#/c/76035/
>
> 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[2].
>
> 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
> discussion)
> - 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
> Icehouse.
>
> 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?
>
I don't think I said indefinitely, and I certainly did not mean
indefinitely.
What is required though, is that we be able to upgrade to the next
release without requiring a new config setting.
Also as we scramble to deal with these things in TripleO (as all of our
users are now unable to spin up new images), it is clear that it is more
than just a setting. One must create domain users carefully and roll out
a new password.
What I'm suggesting is that we should instead _warn_ that the old
behavior is being used and will be deprecated.
At this point, out of urgency, we're landing fixes. But in the future,
this should be considered carefully.
More information about the OpenStack-dev
mailing list