On Wed, Apr 08, 2015 at 10:13:27PM +0200, Gorka Eguileor wrote: > Hi all, > > This message is in relation with a bug on Quota deletion API that > affects both Nova [1] and Cinder [2], so we should discuss together > what's the desired solution as to be consistent in both projects. > > Currently Quota deletion API removes not only Quota limits, but also > Current Quota Usage and Quota Reservations. Which, from an Operator's > point of view doesn't make that much sense, since they expect > preservation of Usage and Reservations. > > I first created a patch for Cinder [3], then seeing that Nova's issue > was the same I created one for Nova as well [4], but the solution was > not unanimously accepted, and it was suggested that a new endpoint > should be created for this new behavior (only deleting Quota limits). > > My reasoning for not creating a new endpoint in the first place and > changing current endpoint instead, is that I saw this as a bug, not a > new feature; I believe delete endpoint, like create, is only meant to > affect Quota limits, as Usage and Reservations are handled by OpenStack > itself. If you cannot create Quota usage you shouldn't be able to > manually delete them either. > > Some additional topics were discussed on IRC and Gerrit: > - Shouldn't delete set quota limits to unlimited instead of deleting > them and thus apply default quota limits?: This is a matter of how the > "Quota delete" is understood, as "Delete quotas and leave no quota > limits, not even defaults" or just "Delete additional quota limits > that override defaults". > - What about cascade deleting a tenant? Wouldn't it need to delete Usage > and Reservations with the same API call?: Since Quota Reservations and > Usage are handled by OpenStack, once related resources are deleted so > will be the pertinent Reservations and Usage Quotas. > > In the matter of setting Quotas to unlimited on deletion I believe we > should keep current behavior, which means it would use defaults or any > other quotas that are in place, for example you delete a User's Quota > limits, but Tenant's limits would still apply. > > As I see it, we should decide if it's OK to change existing endpoint or > if, as it was suggested, we should create a new endpoint with a more > pertinent name, like something related to reset quota limits. > > I, for one, believe we should change current behavior as it's not doing > what it's meant to do. But I must admit that my understanding of how > this endpoint is currently being used and how such a decision affects > services is limited. > > Anyway, I have no problem changing the patches to whatever we decide is > best. > > > Cheers, > Gorka. > > > [1]: https://bugs.launchpad.net/nova/+bug/1410032 > [2]: https://bugs.launchpad.net/cinder/+bug/1410034 > [3]: https://review.openstack.org/#/c/162722/ > [4]: https://review.openstack.org/#/c/163423/ > > __________________________________________________________________________ > 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
Update on the Cinder side: This was discussed in a meeting [1], we agreed to change the API and the patch to fix this has already been merged. The reasons why we considered that changing the API was acceptable were: - It was considered to be a bug: Unlike in Nova, API documentation is more explicit; stating that after deletion it would return to default values, which implies that it's only talking about limits. - It falls within the API change guidelines [2], like the Bugfixed OK example that modifies the counting of hosts. Nova patch has been updated with the same solution in case it is considered a valid fix. Cheers, Gorka. [1]: http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-04-29-16.00.txt [2]: https://wiki.openstack.org/wiki/APIChangeGuidelines __________________________________________________________________________ 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