Open Stack

Hello everyone.

Now I’m working on the patch to OSC that adds 'quota delete' command (former neutron quota-delete, cinder quota-delete and nova quota-delete) [1]
In the past the python-*clients used this command for setting the quotas for resources to default value.
So, some times ago we have a conversation in irc [2] about this "confused" command and the main solution was (with which I agreed) resetting quotas via 'quota set' command with '--default' argument instead of 'quota delete'
But I tried to imagine how a new 'quota set' (with --default argument) command will looks like and I’m not enjoying it.
At the first, in the current state the 'quota set' takes a project/class as a mandatory argument. What will happen if we try to pass a class argument for 'quota set --default'? Actually, there is no classes support for quota delete.
Secondly, I like the idea to pass --compute or/and --volume or/and --network for reseting the respective quotas, but I don't really understand how to properly implement it for 'quota set --default'. It looks like we should split 'quota set' command with old 'quota set' behavior and with the new 'quota set --default'. And I don’t know how it can be represented in the docs and in the cli usage info.
All of this, I believe, will lead to the fact that the 'quota set' will be very complicated for users, not obvious and sometimes unpredictable.
I propose to do not add '—default' to the 'quota set' command. I think that the action that resets quotas to default values needs to be a separate command. But 'quota delete' also is not is not appropriate because delete is really meaning 'remove'.
I propose to call this command 'quota reset' instead of 'quota delete'.
Please tell me what do you think about it.


[1] https://review.openstack.org/#/c/376311/
[2] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2016-10-12.log.html#t2016-10-12T15:01:58

--
Best Regards,
Sergey Belous

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161013/1686ef58/attachment.html>