Open Stack

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-request at 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