On Tue, Jan 28, 2020 at 8:10 AM Dougal Matthews <dougal@redhat.com> wrote:

On Tue, 28 Jan 2020 at 14:54, Dougal Matthews <dougal@redhat.com> wrote:

...

Hey all,

While doing work on the Mistral to Ansible port I was looking at the openstack overcloud plan commands. These are;

- openstack overcloud plan create - openstack overcloud plan delete - openstack overcloud plan deploy - openstack overcloud plan list - openstack overcloud plan export

There has been a useful comment on the review that export is actually useful still. Harald said;

"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."

This seems like a good reason, although it could be argued that Swift is a better tool to download a container.

I've commented but I don't think we're ready to remove these yet until we've gotten off of swift. TBH trying to download a swift container is a painful via openstackcli so I'd rather that we leave these basic commands. Additionally it doesn't require that an end user understand that a plan is stored in swift. End users should be using 'openstack overcloud *' commands to perform actions and not going and doing direct nova/neutron/ironic/swift related actions. We've seen folks do some dangerous stuff when they start toying with the underlying implementations.

...

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].

I am therefore proposing that we remove these commands and skip the normal deprecation process. https://review.opendev.org/#/c/704581/1

What do you think?

Thanks, Dougal

[1]: https://github.com/openstack/python-tripleoclient/blob/3c589979ceb05d732b3c9...

Hi all, In any case, there is another way to get the plan content for debugging purposes: openstack container save overcloud So not sure if the openstack overcloud commands helps a lot, and if it's not redundant with openstack container commands. Mathieu On Wed, Jan 29, 2020 at 2:32 PM Dougal Matthews <dougal@redhat.com> wrote:

On Tue, 28 Jan 2020 at 15:15, Alex Schultz <aschultz@redhat.com> wrote:

...

On Tue, Jan 28, 2020 at 8:10 AM Dougal Matthews <dougal@redhat.com> wrote:

...

On Tue, 28 Jan 2020 at 14:54, Dougal Matthews <dougal@redhat.com>

wrote:

...

...

Hey all,

While doing work on the Mistral to Ansible port I was looking at the

openstack overcloud plan commands. These are;

...

- openstack overcloud plan create - openstack overcloud plan delete - openstack overcloud plan deploy - openstack overcloud plan list - openstack overcloud plan export

There has been a useful comment on the review that export is actually useful still. Harald said;

"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."

This seems like a good reason, although it could be argued that Swift is a better tool to download a container.

I've commented but I don't think we're ready to remove these yet until we've gotten off of swift. TBH trying to download a swift container is a painful via openstackcli so I'd rather that we leave these basic commands. Additionally it doesn't require that an end user understand that a plan is stored in swift. End users should be using 'openstack overcloud *' commands to perform actions and not going and doing direct nova/neutron/ironic/swift related actions. We've seen folks do some dangerous stuff when they start toying with the underlying implementations.

That is fair. Thanks. I guess there are some uses that have emerged even if this work was never fully completed.

I'll start porting them to Ansible instead.

Thanks!

...

...

...

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].

...

...

I am therefore proposing that we remove these commands and skip the

normal deprecation process. https://review.opendev.org/#/c/704581/1

...

What do you think?

Thanks, Dougal

[1]:

https://github.com/openstack/python-tripleoclient/blob/3c589979ceb05d732b3c9...