Domain Quota Driver

Registered by Tiago Martins

Keystone BP Domain Quota Management and Enforcement will enable O~S projects to enforce domain quotas, for this a new driver capable to enforce domain quota is necessary. This BP addresses the need of a new quota driver capable to enforce domain quotas in Nova.

Blueprint information

Status:
Started
Approver:
Russell Bryant
Priority:
Undefined
Drafter:
Tiago Martins
Direction:
Needs approval
Assignee:
Raildo Mascena de Sousa Filho
Definition:
Drafting
Series goal:
None
Implementation:
Beta Available
Milestone target:
None
Started by
Tiago Martins

Related branches

Sprints

Whiteboard

I think this could use some more detailed design documentation. --russellb

Wiki Page: https://wiki.openstack.org/wiki/DomainQuotaDriver --- raildo
Code on GitHub: https://github.com/vinodkumarboppanna/DomainQuotaAPIs

Thanks for the updates. It seems the proposed design is that deployers have a choice between domain quotas or project quotas, and not both. Is that right? Maybe we need to discuss expectations on the mailing list? --russellb

The proposed design is That deployers have a choice between domain project quotas or quotas, and not both or both drivers. The idea is to create a new layer of quotas only this time related to the domain.This was discussed during the last summit, but if it is necessary to discuss in a mainging list, I am available. --raildo

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 think this could use some more detailed design documentation. --russellb

Wiki Page: https://wiki.openstack.org/wiki/DomainQuotaDriver --- raildo
Code on GitHub: https://github.com/vinodkumarboppanna/DomainQuotaAPIs

Thanks for the updates. It seems the proposed design is that deployers have a choice between domain quotas or project quotas, and not both. Is that right? Maybe we need to discuss expectations on the mailing list? --russellb

The proposed design is That deployers have a choice between domain project quotas or quotas, and not both or both drivers. The idea is to create a new layer of quotas only this time related to the domain.This was discussed during the last summit, but if it is necessary to discuss in a mainging list, I am available. --raildo

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)I think this could use some more detailed design documentation. --russellb

Wiki Page: https://wiki.openstack.org/wiki/DomainQuotaDriver --- raildo
Code on GitHub: https://github.com/vinodkumarboppanna/DomainQuotaAPIs

Thanks for the updates. It seems the proposed design is that deployers have a choice between domain quotas or project quotas, and not both. Is that right? Maybe we need to discuss expectations on the mailing list? --russellb

The proposed design is That deployers have a choice between domain project quotas or quotas, and not both or both drivers. The idea is to create a new layer of quotas only this time related to the domain.This was discussed during the last summit, but if it is necessary to discuss in a mainging list, I am available. --raildo

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 think this could use some more detailed design documentation. --russellb

Wiki Page: https://wiki.openstack.org/wiki/DomainQuotaDriver --- raildo
Code on GitHub: https://github.com/vinodkumarboppanna/DomainQuotaAPIs

Thanks for the updates. It seems the proposed design is that deployers have a choice between domain quotas or project quotas, and not both. Is that right? Maybe we need to discuss expectations on the mailing list? --russellb

The proposed design is That deployers have a choice between domain project quotas or quotas, and not both or both drivers. The idea is to create a new layer of quotas only this time related to the domain.This was discussed during the last summit, but if it is necessary to discuss in a mainging list, I am available. --raildo

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)

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

Work items:
Domain Quota Driver methods: DONE
Domain Quota Driver unit tests: DONE