On Tue, Mar 04, 2014 at 02:06:16PM -0800, Clint Byrum wrote: > 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.
So log a warning for one cycle, then it's OK to expect the config after that? I'm still unclear if there's an openstack-wide policy on this, as the whole time-based release with release-notes (which all of openstack is structured around and adheres to) seems to basically be an uncomfortable fit for folks like tripleo who are trunk chasing and doing CI. > 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. Such are the pitfalls of life at the bleeding edge ;) Seriously though, apologies for the inconvenience - I have been asking for feedback on these patches for at least a month, but clearly I should've asked harder. As was discussed on IRC yesterday, I think some sort of (initially non-voting) feedback from tripleo CI to heat gerrit is pretty much essential given that you're so highly coupled to us or this will just keep happening. > 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. Ok, well I raised this bug: https://bugs.launchpad.net/heat/+bug/1287980 So we can modify the stuff so that it falls back to the old behavior gracefully and will solve the issue for folks on the time-based releases. Hopefully we can work towards the tripleo gate feedback so next time this is less of a suprise for all of us ;) Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
