Re: [openstack-dev] [nova][novaclient] Responses for Deletion Events

[Dean Troyer]

On Sun, Mar 27, 2016 at 7:56 PM, Matt Riedemann 
wrote:
>
> The novaclient CLI is supposed to be more or less deprecated (for awhile
> now), but because of a lack of microversion support in the openstackclient
> CLI we've continued making changes to novaclient CLI.
>

We're climbing that particular hill now...


> In this case, we could just say we're not fixing it for novaclient and if
> you want it, add the behavior to openstackclient. That team probably has
> guidelines (at least in Dean's head) around how verbose a delete operation
> should be.
>

These sorts of things are getting extracted from my (and others') heads
into the devref docs.  With the default logging settings we have no output
for delete commands unless an error has occurred.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][novaclient] Responses for Deletion Events

[Matt Riedemann]

On 3/23/2016 4:53 PM, Augustina Ragwitz wrote:

There's been some discussion regarding a recent bug [1] where an issue
was reported that no confirmation/success message is received from "nova
agent-delete". This behavior is inconsistent from other novaclient
delete commands which do provide a success message.

There are a two issues that need to be addressed before this behavior
can be patched:

1) What would represent sufficient expected behavior in this deletion case?

A few options have been suggested in the bug; we should probably have
consensus. We should keep in mind the novaclient is due to be deprecated
in the near future, to be replaced by the openstack-client.

The options suggested include providing a simple success response or
supporting different levels of response data with options. For instance,
only show a message if the user specifies --verbose explicitly.
novaclient is not consistent with its "delete" behavior, some calls
require --verbose while others are verbose by default.

2) How does the openstack-client behave for deletions? Should we be
consistent with that in our own client?

I've been digging around in the available documentation for the
OpenStack client and didn't see response types documented. This issue
has also not been addressed in any of the HGI or other high level
documentation. I posted a question in the #openstack-sdks channel to see
if anyone knows the answer to this.

This might be a good opportunity to think about a standard for deletion
responses if one hasn't been defined already.


[1] https://bugs.launchpad.net/python-novaclient/+bug/1557888

---
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



The novaclient CLI is supposed to be more or less deprecated (for awhile 
now), but because of a lack of microversion support in the 
openstackclient CLI we've continued making changes to novaclient CLI.


In this case, we could just say we're not fixing it for novaclient and 
if you want it, add the behavior to openstackclient. That team probably 
has guidelines (at least in Dean's head) around how verbose a delete 
operation should be.


If we did implement something in novaclient, I'd lean toward making the 
user provide a --verbose option to get some output. After all, it's a 
CLI. If it works, you get a 0 exit code. If it fails, you get a non-0 
exit code and some error message.


I can see why `nova delete` is maybe a bit more verbose since it's a 
cast in the API. Deleting an agent isn't, it's a straight DB delete 
operation from the REST API, so it either works right away or it 
doesn't, so I think the exit code is sufficient in the default case (no 
--verbose option that is).


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev