Expose detail quota usage information in v2 api
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:/
[2] https:/
[3] http://
[4] https:/
Blueprint information
Related branches
Related bugs
| Bug #1183870: os-quota-sets should show 'in use' and 'Reserved' | Fix Released |
| Bug #1264043: Inconsistency between os-quota-sets code and API doc | Confirmed |
Sprints
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-
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://
[2] https:/
[3] https:/
Gerrit topic: https:/
Addressed by: https:/
Expose quota detail with os-quota-detail API extension
client support:
Addressed by: https:/
Add quota usage support for V2 API
deferred from icehouse-3 to "next": http://
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-
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://
[2] https:/
[3] https:/
Gerrit topic: https:/
Addressed by: https:/
Expose quota detail with os-quota-detail API extension
client support:
Addressed by: https:/
Add quota usage support for V2 API
deferred from icehouse-3 to "next": http://
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)
