<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/11/2014 04:04 AM, Sean Dague
wrote:<br>
</div>
<blockquote cite="mid:531EEDC0.9020303@dague.net" type="cite">
<pre wrap="">On 03/04/2014 12:39 PM, Steven Hardy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/73978/">https://review.openstack.org/#/c/73978/</a>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/76035/">https://review.openstack.org/#/c/76035/</a>
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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
Sean,<br>
<br>
I agree the Heat community hasn't done a bang-up job of getting
integrated with Tempest. We only have 50 functional tests
implemented. The community clearly needs to do more and provide
better functional coverage with Heat.<br>
<br>
It is inappropriate to say "Only monday did we finally start gating"
because that was a huge move in the right direction. It took alot
of effort and should not be so easily dismissed. Clearly the
community, and especially the core developers, are making an
effort. Keep in mind we have to balance upstream development work,
answering user questions, staying on top of a 5 page review queue,
keeping relationships and track of the various integrated projects
which are consuming Heat as a building block, plus all of the
demands of our day jobs.<br>
<br>
We just don't have enough bandwidth on the core team to tackle
writing all of the tempest test cases ourselves. We have made an
effort to distribute this work to the overall heat community via
wishlist bugs in Heat which several new folks have picked up. I
hope to see our coverage improve over time, especially with more
advanced scenario tests through this effort.<br>
<br>
Regards<br>
-steve<br>
<br>
<blockquote cite="mid:531EEDC0.9020303@dague.net" type="cite">
<pre wrap="">
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.
-Sean
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>