<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 28 Jan 2020 at 15:15, Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@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">On Tue, Jan 28, 2020 at 8:10 AM Dougal Matthews <<a href="mailto:dougal@redhat.com" target="_blank">dougal@redhat.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, 28 Jan 2020 at 14:54, Dougal Matthews <<a href="mailto:dougal@redhat.com" target="_blank">dougal@redhat.com</a>> wrote:<br>
>><br>
>> Hey all,<br>
>><br>
>> While doing work on the Mistral to Ansible port I was looking at the openstack overcloud plan commands. These are;<br>
>><br>
>> - openstack overcloud plan create<br>
>> - openstack overcloud plan delete<br>
>> - openstack overcloud plan deploy<br>
>> - openstack overcloud plan list<br>
>> - openstack overcloud plan export<br>
><br>
><br>
> There has been a useful comment on the review that export is actually useful still. Harald said;<br>
><br>
> "I find the possibility to download the plan on a failed deployment quite valuable. It allows me to read the heat templates in a more human friendly fully rendered version compared to the j2, run yaml validation tools etc. There is *magic* adding stuff to plan's that I can't see by simply running process templates tools."<br>
><br>
> This seems like a good reason, although it could be argued that Swift is a better tool to download a container.<br>
><br>
<br>
I've commented but I don't think we're ready to remove these yet until<br>
we've gotten off of swift. TBH trying to download a swift container is<br>
a painful via openstackcli so I'd rather that we leave these basic<br>
commands. Additionally it doesn't require that an end user understand<br>
that a plan is stored in swift. End users should be using 'openstack<br>
overcloud *' commands to perform actions and not going and doing<br>
direct nova/neutron/ironic/swift related actions. We've seen folks do<br>
some dangerous stuff when they start toying with the underlying<br>
implementations.<br></blockquote><div><br></div><div>That is fair. Thanks. I guess there are some uses that have emerged even if this work was never fully completed.</div><div><br></div><div>I'll start porting them to Ansible instead.</div><div><br></div><div>Thanks!<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">
<br>
><br>
>><br>
>><br>
>> I believe none of these commands make sense in a post-TripleO UI world. There is no other way to interact and update a plan. Deploys are always done via "openstack overcloud deploy" and this deletes the contents of the plan container and repopulates it with the local files[1].<br>
>><br>
>> I am therefore proposing that we remove these commands and skip the normal deprecation process. <a href="https://review.opendev.org/#/c/704581/1" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/704581/1</a><br>
>><br>
>> What do you think?<br>
>><br>
>> Thanks,<br>
>> Dougal<br>
>><br>
>><br>
>> [1]: <a href="https://github.com/openstack/python-tripleoclient/blob/3c589979ceb05d732b3c924eb919e145e22efaa8/tripleoclient/workflows/plan_management.py#L211" rel="noreferrer" target="_blank">https://github.com/openstack/python-tripleoclient/blob/3c589979ceb05d732b3c924eb919e145e22efaa8/tripleoclient/workflows/plan_management.py#L211</a><br>
<br>
</blockquote></div></div>