Open Stack

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 at redhat.com> wrote:

>
>
> On Tue, 28 Jan 2020 at 15:15, Alex Schultz <aschultz at redhat.com> wrote:
>
>> On Tue, Jan 28, 2020 at 8:10 AM Dougal Matthews <dougal at redhat.com>
>> wrote:
>> >
>> >
>> >
>> > On Tue, 28 Jan 2020 at 14:54, Dougal Matthews <dougal at 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/3c589979ceb05d732b3c924eb919e145e22efaa8/tripleoclient/workflows/plan_management.py#L211
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200129/c5169e0f/attachment.html>