<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2019 at 3:18 AM Dougal Matthews <<a href="mailto:dougal@redhat.com">dougal@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey all,</div><div><br></div><div>As some of you will know there is work going on to replace Mistral with Ansible. There is an initial spec[1]   and a few in-flight patches here to create the initial playbooks. In doing this work, I hit an issue I wanted to get some input in.</div><div><br></div><div>first the tl;dr - what is our policy on changing the output from tripleoclient? It is proving difficult to keep it the same and in some cases changes will be required (we won't have Mistral execution IDs to print for example).</div><div><br></div></div></blockquote><div><br></div><div>I don't think for the deployment commands that we have any expectation of a specific format. There was a large change during the Rocky timeframe when we switched over to the ansible driven deployment.  That being said there have been requests to improve the output logging for the deployment as we currently use print rather than the proper logging module. This means that --log-file doesn't actually capture any of the deployment output (not ideal).</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"><div dir="ltr"><div></div><div>As a quick reminder, in the current code we print from tripleoclient and Mistral sends messages via Zaqar to tripleoclient (which it then prints). This allows for "real time" updates from workflows. For example, introspection will print updates as introspection of nodes is completed. With Ansible it is tricky to have this same result.</div><div><br></div><div>I can think of three options;</div><div><br></div><div>1. We run Ansible in the background, essentially hiding it and then polling OpenStack services to look for the expected state changes. We can then display this to the user.</div></div></blockquote><div><br></div><div>Let's not do this since the output is already presented to the user for the undercloud/overcloud today.</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"><div dir="ltr"><div><br></div><div>2. We go for a "ansible native" approach and stream the ansible output to the user. This will be familiar to anyone familiar with Ansible but it will mean the output completely changes. This is also the easiest option (from an implementation point of view)<br></div><div><br></div></div></blockquote><div><br></div><div>We already do this for the `openstack tripleo deploy` command so I would use that as it's likely the simplest and more closely resembles what we have today.</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"><div dir="ltr"><div></div><div>3. I have not tested this idea, but I think we could have a custom Ansible module that writes messages to a tempfile. tripleoclient could then consume them and display them to the user. This would be similar to idea 1, but rather than polling services we constantly read a file and display those "messages" from ansible. This would be closest to the current Mistral and Zaqar solution.<br></div><div><br></div></div></blockquote><div><br></div><div>Sounds overly complex and prone to failures.</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"><div dir="ltr"><div></div><div><br></div><div>Personally I am a bit torn. One of the reasons we want to use Ansible is because developers/users are more familiar with debugging it. However, if we hide ansible that might not help very much. So I think in the long run option 2 might be best. However, that completely changes the output, it limits us to what Ansible can output and frankly, in my experience, Ansible output is ugly and often hard to read. <br></div><div><br></div><div>I am curious to know what y'all think and hopefully there are some other options too.<br></div><div><br></div><div>Thanks,</div><div>Dougal<br></div><div><br></div><div><br></div><div>[1] <a href="https://review.opendev.org/#/c/679272/" target="_blank">https://review.opendev.org/#/c/679272/</a></div><div>[2] <a href="https://review.opendev.org/#/q/status:open+topic:mistral_to_ansible" target="_blank">https://review.opendev.org/#/q/status:open+topic:mistral_to_ansible</a></div></div>
</blockquote></div></div>