Open Stack

On Tue, Mar 11, 2014 at 07:04:32AM -0400, Sean Dague wrote:
> 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[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?
> 
> 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
> having again.
> 
> 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.

Thanks for this, I know we have a lot more work to do in tempest, but
evidently grenade integration is something we should priotitize as soon as
possible.  Any volunteers out there? :)

> 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.

Ok, got that message loud and clear now, thanks ;)

Do you have a link to docs which describe the deprecation cycle and
openstack-wide policy for introducing backwards incompatible changes?

The thing I'm still not that clear on, is if we want to eventually require
a specific config option, and we can't just have an upgrade requirement to
add it as I was expecting - is it enough to just output a warning for one
release cycle then require it?

Then I guess my question is how do we rationalize the requirements of
trunk-chasing downstream users wrt the time based releases as part of the
deprecation cycle policy?

i.e if we branch stable/icehouse then I immediately post a patch removing
the deprecated fallback path, it may still break downstream users who don't
care about the stable-branch process and I have no way of knowing (other
than, as in this case, finding out too late when they shout at me..).

Thanks for contributing to the discussion, hopefully it's not only me who's
somewhat confused by the process, and the requirement to satisfy two quite
different sets of release constraints for downstream deployers.

Perhaps we need a wiki page similar to the StableBranch page which spells
out the requirements for projects wrt trunk-chasing deployers, unless one
exists already?.

Steve