<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 7:27 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 08, 2017 at 02:45:08PM +0300, 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 and<br>
> 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 status.<br>
> It was pointed out by shardy that for such checks it is better to instead<br>
</span>> continue to use the per-service  manifests where possible like [2] for<br>
<span class="">> example where we check status before N..O major upgrade. There may still<br>
> be some undercloud specific validations that we can land into the<br>
> tripleo-validations repo (thinking about things like the neutron<br>
> networks/ports, validating the current nova nodes state etc?).<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 an<br>
> ansible playbook that the operator can invoke for upgrade of the 'manual'<br>
> nodes (for example compute in the N..O workflow) - the point being that we<br>
> can add more per-service ansible validation tasks into the service<br>
> manifests for execution when the play is run by the operator - but I'll<br>
</span>> let Steve point at and talk about those. <br>
<br>
Thanks for starting this thread Marios, sorry for the slow reply due to<br>
Summit etc.<br>
<br>
As we discussed, I think adding validations is great, but I'd prefer we<br>
kept any overcloud validations specific to services in t-h-t instead of<br>
trying to manage service specific things over multiple repos.<br>
<br>
This would also help with the idea of per-step validations I think, where<br>
e.g you could have a "is service active" test and run it after the step<br>
where we expect the service to start, a blueprint was raised a while back<br>
asking for exactly that:<br>
<br>
<a href="https://blueprints.launchpad.net/tripleo/+spec/step-by-step-validation" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/tripleo/+spec/step-by-<wbr>step-validation</a><br>
<br></blockquote><div><br></div><div>thanks for this we can use it one less to file :D</div><div><br></div><div>and ack on the overcloud vs undercloud - sounds like tripleo-validations is the right place/folks agree in general to having some ansible tasks there to validate _stuff_ (thanks very much @bnemec and @emilien for suggestions</div><div><br></div><div>thanks</div></div><br></div></div>