<p dir="ltr">Well we probably need some backwards compat glue to keep deploying supported versions. More on that in the spec I'm drafting.</p>
<div class="gmail_quote">On 21 Jun 2014 12:26, "Dan Prince" <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 2014-06-20 at 16:51 -0400, Charles Crouch wrote:<br>
><br>
> ----- Original Message -----<br>
> > Not a great week for TripleO CI. We had 3 different failures related to:<br>
> ><br>
> >  Nova [1]: we were using a deprecated config option<br>
> >  Heat [2]: missing heat data obtained from the Heat CFN API<br>
> >  Neutron [3]: a broken GRE overlay network setup<br>
><br>
> The last two are bugs, but is there anything tripleo can do about avoiding the first one in the future?:<br>
<br>
Yes. Reviewing and monitoring our log files would have been helpful<br>
here. Nova did nothing wrong... we were just plain using an old option<br>
which was deprecated in Icehouse.<br>
<br>
With TripleO's upstream focus we need to maintain a balancing act and<br>
try to avoid using new option names until a release has been made. I<br>
think once the release is made however (Icehouse in this case) we should<br>
immediately move to drop all deprecated options and use the new<br>
versions. If we follow a process like this we should be safe guarded<br>
from this sort of failure in the future.<br>
<br>
Dan<br>
<br>
> e.g. reviewing a list of deprecated options and seeing when they will be removed.<br>
><br>
> do the integrated projects have a protocol for when an option is deprecated and at what point it can be removed?<br>
> e.g. if I make something deprecated in icehouse I can remove it in juno, but if I<br>
> make something deprecated at the start of juno I can't remove it at the end of juno?<br>
><br>
> ><br>
> > The TripleO check jobs look to be running stable again today so if your<br>
> > patch had failures from earlier this week then recheck away (perhaps<br>
> > referencing one of these bugs if appropriate). The queue is fairly empty<br>
> > right now...<br>
> ><br>
> > Thanks for all the help in tracking these down and getting things fixed.<br>
> ><br>
> > [1] <a href="https://bugs.launchpad.net/tripleo/+bug/1292105" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1292105</a><br>
><br>
> I think [1] was meant to be<br>
> <a href="https://bugs.launchpad.net/tripleo/+bug/1330735" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1330735</a><br>
><br>
> > [2] <a href="https://bugs.launchpad.net/heat/+bug/1331720" target="_blank">https://bugs.launchpad.net/heat/+bug/1331720</a><br>
> > [3] <a href="https://bugs.launchpad.net/tripleo/+bug/1292105" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1292105</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>