Expose detail quota usage information in v2 api

Registered by Qiu Yu on 2013-12-25

In an earlier fix for bug 1186870 [1], patch has been merged to allow V3 api display quota information in detail (In_use, Reserved and Limit).

Since it is a useful feature, and V2 api gonna be around for long time[2], and V3 api is not official yet, this blueprint will backport this feature to V2 api.

Due to API stability concern [4], it will be implemented as a separate API extension.

[1] https://bugs.launchpad.net/nova/+bug/1183870
[2] https://etherpad.openstack.org/p/icehouse-summit-nova-v3-api
[3] http://api.openstack.org/api-ref-compute.html#os-quota-sets
[4] https://wiki.openstack.org/wiki/APIChangeGuidelines

Blueprint information

Status:
Started
Approver:
None
Priority:
Undefined
Drafter:
Qiu Yu
Direction:
Needs approval
Assignee:
Qiu Yu
Definition:
Drafting
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
None
Started by
Qiu Yu on 2013-12-27

Whiteboard

I would rather see effort be made into getting v3 out the door instead of backporting to v2 -- jogo

Sure. My understanding is that V3 support for this feature is done. Since V2 gonna be around for a while, this could be a handy feature useful for those deployers still running V2 api. --unicell

We don't want to be actively developing two APIs, so if someone wants this feature they should run v3 API. There is no reason someone can't run both v2 and v3 if they want. --jogo

I do realized it is *encouraged* to put develop effort on v3 rather then v2, as you mentioned in following email thread[1]. Hoever, since a) v2 is not frozen yet at this moment, b) it is not forbidden to update v2 api since it is not frozen yet, c) benefits for deployers sticks to v2 for the moment, migration do takes time. Running v2 and v3 at the same time is possible, but one also need to switch env virable or specify --os-compute-api-version at client side. --unicell

This BP is targeted for Icehouse-3 at which point v2 will be frozen. I still don't think this is worth it even if this makes it v2. Back-porting v3 feature sets the wrong precedent. --jogo

To me, it is more like fixing a usability issue here. This is why the original patchset [2] was created to solve the bug #1183870 [3]. Looking through the code review comments, original author seems misunderstood Russell's comments (on patchset 3 and 6) and left the portion for v2, which my patch trying to fix. BTW, the code is ready, we can make it Icehouse-2 if that is possible to be approved for. --unicell

with 424 open nova reviews and icehouse-2 only two weeks away its about triage. I still think backporting v3 to v2 is the wrong precedent especially so close to i2. --jogo

[1] http://openstack.10931.n7.nabble.com/OpenStack-Nova-API-Still-need-to-update-v2-API-in-Icehouse-release-td27841.html
[2] https://review.openstack.org/#/c/32303/
[3] https://bugs.launchpad.net/nova/+bug/1183870

Gerrit topic: https://review.openstack.org/#q,topic:bp/expose-quota-details,n,z

Addressed by: https://review.openstack.org/64017
    Expose quota detail with os-quota-detail API extension

client support:
Addressed by: https://review.openstack.org/64088
    Add quota usage support for V2 API

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyI would rather see effort be made into getting v3 out the door instead of backporting to v2 -- jogo

Sure. My understanding is that V3 support for this feature is done. Since V2 gonna be around for a while, this could be a handy feature useful for those deployers still running V2 api. --unicell

We don't want to be actively developing two APIs, so if someone wants this feature they should run v3 API. There is no reason someone can't run both v2 and v3 if they want. --jogo

I do realized it is *encouraged* to put develop effort on v3 rather then v2, as you mentioned in following email thread[1]. Hoever, since a) v2 is not frozen yet at this moment, b) it is not forbidden to update v2 api since it is not frozen yet, c) benefits for deployers sticks to v2 for the moment, migration do takes time. Running v2 and v3 at the same time is possible, but one also need to switch env virable or specify --os-compute-api-version at client side. --unicell

This BP is targeted for Icehouse-3 at which point v2 will be frozen. I still don't think this is worth it even if this makes it v2. Back-porting v3 feature sets the wrong precedent. --jogo

To me, it is more like fixing a usability issue here. This is why the original patchset [2] was created to solve the bug #1183870 [3]. Looking through the code review comments, original author seems misunderstood Russell's comments (on patchset 3 and 6) and left the portion for v2, which my patch trying to fix. BTW, the code is ready, we can make it Icehouse-2 if that is possible to be approved for. --unicell

with 424 open nova reviews and icehouse-2 only two weeks away its about triage. I still think backporting v3 to v2 is the wrong precedent especially so close to i2. --jogo

[1] http://openstack.10931.n7.nabble.com/OpenStack-Nova-API-Still-need-to-update-v2-API-in-Icehouse-release-td27841.html
[2] https://review.openstack.org/#/c/32303/
[3] https://bugs.launchpad.net/nova/+bug/1183870

Gerrit topic: https://review.openstack.org/#q,topic:bp/expose-quota-details,n,z

Addressed by: https://review.openstack.org/64017
    Expose quota detail with os-quota-detail API extension

client support:
Addressed by: https://review.openstack.org/64088
    Add quota usage support for V2 API

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.