[cinder][ops] Nested Quota Driver Use?
Hey everyone, I'm hoping to get some feedback from folks, especially operators. In the Liberty release, Cinder introduced the ability to use a Nest Quota Driver to handle cases of heirarchical projects and quota enforcement [0]. I have not heard of anyone actually using this. I also haven't seen any bugs filed, which makes me a little suspicious given how complicated it can be. I would like to know if any operators are using this for nested quotas. There is an effort underway for a new mechanism called "unified limits" that will require a lot of modifications to the Cinder code. If this quota driver is not needed, I would like to deprecated it in Train so it can be removed in the U release and hopefully prevent some unnecessary work being done. Any feedback on this would be appreciated. Thanks! Sean [0] https://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nest...
We're interested in the overall functionality but I think unified limits is the place to invest and thus would not have any problem deprecating this driver. We'd really welcome this being implemented across all the projects in a consistent way. The sort of functionality proposed in https://techblog.web.cern.ch/techblog/post/nested-quota-models/ would need Nova/Cinder/Manila at miniumum for CERN to switch. So, no objections to deprecation but strong support to converge on unified limits. Tim -----Original Message----- From: Sean McGinnis <sean.mcginnis@gmx.com> Date: Thursday, 2 May 2019 at 02:39 To: "openstack-discuss@lists.openstack.org" <openstack-discuss@lists.openstack.org> Subject: [cinder][ops] Nested Quota Driver Use? Hey everyone, I'm hoping to get some feedback from folks, especially operators. In the Liberty release, Cinder introduced the ability to use a Nest Quota Driver to handle cases of heirarchical projects and quota enforcement [0]. I have not heard of anyone actually using this. I also haven't seen any bugs filed, which makes me a little suspicious given how complicated it can be. I would like to know if any operators are using this for nested quotas. There is an effort underway for a new mechanism called "unified limits" that will require a lot of modifications to the Cinder code. If this quota driver is not needed, I would like to deprecated it in Train so it can be removed in the U release and hopefully prevent some unnecessary work being done. Any feedback on this would be appreciated. Thanks! Sean [0] https://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nest...
On Fri, May 03, 2019 at 06:58:41PM +0000, Tim Bell wrote:
We're interested in the overall functionality but I think unified limits is the place to invest and thus would not have any problem deprecating this driver.
We'd really welcome this being implemented across all the projects in a consistent way. The sort of functionality proposed in https://techblog.web.cern.ch/techblog/post/nested-quota-models/ would need Nova/Cinder/Manila at miniumum for CERN to switch.
So, no objections to deprecation but strong support to converge on unified limits.
Tim
Thanks Tim, that helps. Since there wasn't any other feedback, and no one jumping up to say they are using it today, I have submitted https://review.opendev.org/657511 to deprecated the current quota driver so we don't have to try to refactor that functionality into whatever we need to do for the unified limits support. If anyone has any concerns about this plan, please feel free to raise them here or on that review. Thanks! Sean
On 5/7/2019 9:20 AM, Sean McGinnis wrote:
On Fri, May 03, 2019 at 06:58:41PM +0000, Tim Bell wrote:
We're interested in the overall functionality but I think unified limits is the place to invest and thus would not have any problem deprecating this driver.
We'd really welcome this being implemented across all the projects in a consistent way. The sort of functionality proposed in https://techblog.web.cern.ch/techblog/post/nested-quota-models/ would need Nova/Cinder/Manila at miniumum for CERN to switch.
So, no objections to deprecation but strong support to converge on unified limits.
Tim
Thanks Tim, that helps.
Since there wasn't any other feedback, and no one jumping up to say they are using it today, I have submitted https://review.opendev.org/657511 to deprecated the current quota driver so we don't have to try to refactor that functionality into whatever we need to do for the unified limits support.
If anyone has any concerns about this plan, please feel free to raise them here or on that review.
Thanks! Sean
Sean, If I remember correctly, IBM had put some time into trying to fix the nested quota driver back around the Kilo or Liberty release. I haven't seen much activity since then. I am in support deprecating the driver and going to unified limits given that that appears to be the general direction of OpenStack. Jay
On 5/7/19 3:22 PM, Jay Bryant wrote:
On 5/7/2019 9:20 AM, Sean McGinnis wrote:
On Fri, May 03, 2019 at 06:58:41PM +0000, Tim Bell wrote:
We're interested in the overall functionality but I think unified limits is the place to invest and thus would not have any problem deprecating this driver.
We'd really welcome this being implemented across all the projects in a consistent way. The sort of functionality proposed in https://techblog.web.cern.ch/techblog/post/nested-quota-models/ would need Nova/Cinder/Manila at miniumum for CERN to switch.
So, no objections to deprecation but strong support to converge on unified limits.
Tim
Thanks Tim, that helps.
Since there wasn't any other feedback, and no one jumping up to say they are using it today, I have submitted https://review.opendev.org/657511 to deprecated the current quota driver so we don't have to try to refactor that functionality into whatever we need to do for the unified limits support.
If anyone has any concerns about this plan, please feel free to raise them here or on that review.
Thanks! Sean
Sean,
If I remember correctly, IBM had put some time into trying to fix the nested quota driver back around the Kilo or Liberty release. I haven't seen much activity since then.
I am in support deprecating the driver and going to unified limits given that that appears to be the general direction of OpenStack.
If you happen to notice anyone else contributing to the cinder-specific implementation, feel free to have them reach out to us. If people are interested in developing and adopting unified limits, we're happy to get them up-to-speed on the current approach.
Jay
participants (4)
-
Jay Bryant
-
Lance Bragstad
-
Sean McGinnis
-
Tim Bell