<div dir="ltr"><div>We should also add support for the openstack client to launch the other validators that are used in the GUI. There are validators for the overcloud as well, and new validators are added all the time.</div><div><br></div><div>These validators are installed under /usr/share/openstack-tripleo-validations/validations/ and they're launched by the command:<br></div><div><div id="gmail-polarion-dle-clipboard-container" class="gmail-polarion-dle-clipboard-container"><span id="gmail-polarion_source=RHELOpenStackPlatform/OSP-d UI/Validators"></span>ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/<<validator-name.py>></div><div class="gmail-polarion-dle-clipboard-container"><br></div><div class="gmail-polarion-dle-clipboard-container">Cedric, feel free to open an RFE.<br></div><div class="gmail-polarion-dle-clipboard-container"><br></div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>Regards,<br></div>Udi Kalifon; Senior QE; RHOS-UI<span> Automation</span><br><br></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@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, Jul 16, 2018 at 11:27 AM Cédric Jeanneret <<a href="mailto:cjeanner@redhat.com">cjeanner@redhat.com</a>> wrote:<br>
><br>
> Dear Stackers,<br>
><br>
> In order to let operators properly validate their undercloud node, I<br>
> propose to create a new subcommand in the "openstack undercloud" "tree":<br>
> `openstack undercloud validate'<br>
><br>
> This should only run the different validations we have in the<br>
> undercloud_preflight.py¹<br>
> That way, an operator will be able to ensure all is valid before<br>
> starting "for real" any other command like "install" or "upgrade".<br>
><br>
> Of course, this "validate" step is embedded in the "install" and<br>
> "upgrade" already, but having the capability to just validate without<br>
> any further action is something that can be interesting, for example:<br>
><br>
> - ensure the current undercloud hardware/vm is sufficient for an update<br>
> - ensure the allocated VM for the undercloud is sufficient for a deploy<br>
> - and so on<br>
><br>
> There are probably other possibilities, if we extend the "validation"<br>
> scope outside the "undercloud" (like, tripleo, allinone, even overcloud).<br>
><br>
> What do you think? Any pros/cons/thoughts?<br>
<br>
</span>I think this command could be very useful. I'm assuming the underlying<br>
implementation would call a 'heat stack-validate' using an ephemeral<br>
heat-all instance. If so way we implement it for the undercloud vs the<br>
'standalone' use case would likely be a bit different. We can probably<br>
subclass the implementations to share common code across the efforts<br>
though.<br>
<br>
For the undercloud you are likely to have a few extra 'local only'<br>
validations. Perhaps extra checks for things on the client side.<br>
<br>
For the all-in-one I had envisioned using the output from the 'heat<br>
stack-validate' to create a sample config file for a custom set of<br>
services. Similar to how tools like Packstack generate a config file<br>
for example.<br>
<br>
Dan<br>
<span class=""><br>
><br>
> Cheers,<br>
><br>
> C.<br>
><br>
><br>
><br>
> ¹<br>
> <a href="http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/tripleoclient/v1/undercloud_preflight.py" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/python-<wbr>tripleoclient/tree/<wbr>tripleoclient/v1/undercloud_<wbr>preflight.py</a><br>
> --<br>
> Cédric Jeanneret<br>
> Software Engineer<br>
> DFG:DF<br>
><br>
</span>> ______________________________<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>
______________________________<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>
</blockquote></div><br></div>