Open Stack

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