<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 4:09 AM, Graeme Gillies <span dir="ltr"><<a href="mailto:ggillies@redhat.com" target="_blank">ggillies@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 08/05/17 21:45, Marios Andreou wrote:<br>
> Hi folks, after some discussion locally with colleagues about improving<br>
> the upgrades experience, one of the items that came up was pre-upgrade<br>
> and update validations. I took an AI to look at the current status of<br>
> tripleo-validations [0] and posted a simple WIP [1] intended to be run<br>
> before an undercloud update/upgrade and which just checks service<br>
> status. It was pointed out by shardy that for such checks it is better<br>
> to instead continue to use the per-service  manifests where possible<br>
> like [2] for example where we check status before N..O major upgrade.<br>
> There may still be some undercloud specific validations that we can land<br>
> into the tripleo-validations repo (thinking about things like the<br>
> neutron networks/ports, validating the current nova nodes state etc?).<br>
><br>
> So do folks have any thoughts about this subject - for example the kinds<br>
> of things we should be checking - Steve said he had some reviews in<br>
> progress for collecting the overcloud ansible puppet/docker config into<br>
> an ansible playbook that the operator can invoke for upgrade of the<br>
> 'manual' nodes (for example compute in the N..O workflow) - the point<br>
> being that we can add more per-service ansible validation tasks into the<br>
> service manifests for execution when the play is run by the operator -<br>
> but I'll let Steve point at and talk about those.<br>
><br>
> cheers, marios<br>
><br>
> [0] <a href="https://github.com/openstack/tripleo-validations" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>tripleo-validations</a><br>
> [1] <a href="https://review.openstack.org/#/c/462918/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/462918/</a><br>
> [2]  <a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/neutron-api.yaml#L197" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>tripleo-heat-templates/blob/<wbr>stable/ocata/puppet/services/<wbr>neutron-api.yaml#L197</a><br>
><br>
><br>
</div></div><span class="gmail-">> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
</span>Hi Marios,<br>
<br>
Forgive me if I misunderstand here, but it looks like part of this goal<br>
is to do things like ensure the overcloud is in a decent state before an<br>
upgrade/update is executed.<br>
<br>
How would this work in a situation where I have hit an openstack bug<br>
which causes my cinder service to stop working/fail, and I a fix has<br>
been created/packaged, ready for me to update my overcloud with, but the<br>
validations bomb out because cinder isn't running (and I can't update my<br>
overcloud to the newest package with the fix because the validation fails?)<br>
<br></blockquote><div><br></div><div>o/ right... so there are roughly two groups of things here - validations for the undercloud (of which we don't have much and we want to add some) and validations for the overcloud. For the former we are targetting tripleo-validations and for the latter adding to the existing service checks in the tripleo-heat-template service manifests for execution during the upgrade.</div><div><br></div><div>For both we need a way to disable them - one of the key concerns is the scenario you describe. For the overcoud service checks we already have that at least for the current simple "is service running " (grep SkipUpgradeConfigTags at <a href="https://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html">https://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html</a>). For the tripleo-validations I believe there is a 'validations fatal' type flag already that you can pass to the client.</div><div><br></div><div>hope it answers your concern</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
<br>
Graeme<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Graeme Gillies<br>
Principal Systems Administrator<br>
Openstack Infrastructure<br>
Red Hat Australia<br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>