On Mon, Jun 2, 2014 at 12:29 PM, Matt Riedemann <[email protected]> wrote:
> > > On 6/2/2014 12:53 PM, Joe Gordon wrote: > >> >> >> >> On Thu, May 29, 2014 at 10:46 AM, Matt Riedemann >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote: >> >> I’m not sure that this is the right approach. We really have to >> add the old extension back for compatibility, so it might be >> best to simply keep that extension instead of adding a new way >> to do it. >> >> Vish >> >> On May 27, 2014, at 1:31 PM, Cazzolato, Sergio J >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> I have created a blueprint to add this functionality to nova. >> >> https://review.openstack.org/#__/c/94519/ >> >> <https://review.openstack.org/#/c/94519/> >> >> >> -----Original Message----- >> From: Vishvananda Ishaya [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Tuesday, May 27, 2014 5:11 PM >> To: OpenStack Development Mailing List (not for usage >> questions) >> Subject: Re: [openstack-dev] [nova] nova default quotas >> >> Phil, >> >> You are correct and this seems to be an error. I don't think >> in the earlier ML thread[1] that anyone remembered that the >> quota classes were being used for default quotas. IMO we >> need to revert this removal as we (accidentally) removed a >> Havana feature with no notification to the community. I've >> reactivated a bug[2] and marked it critcal. >> >> Vish >> >> [1] >> http://lists.openstack.org/__pipermail/openstack-dev/2014-_ >> _February/027574.html >> <http://lists.openstack.org/pipermail/openstack-dev/2014- >> February/027574.html> >> [2] https://bugs.launchpad.net/__nova/+bug/1299517 >> >> <https://bugs.launchpad.net/nova/+bug/1299517> >> >> On May 27, 2014, at 12:19 PM, Day, Phil <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Vish, >> >> I think quota classes have been removed from Nova now. >> >> Phil >> >> >> Sent from Samsung Mobile >> >> >> -------- Original message -------- >> From: Vishvananda Ishaya >> Date:27/05/2014 19:24 (GMT+00:00) >> To: "OpenStack Development Mailing List (not for usage >> questions)" >> Subject: Re: [openstack-dev] [nova] nova default quotas >> >> Are you aware that there is already a way to do this >> through the cli using quota-class-update? >> >> http://docs.openstack.org/__ >> user-guide-admin/content/cli___set_quotas.html >> >> <http://docs.openstack.org/user-guide-admin/content/cli_ >> set_quotas.html> >> (near the bottom) >> >> Are you suggesting that we also add the ability to use >> just regular quota-update? I'm not sure i see the need >> for both. >> >> Vish >> >> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> I would to hear your thoughts about an idea to add a >> way to manage the default quota values through the >> API. >> >> The idea is to use the current quota api, but >> sending ''default' instead of the tenant_id. This >> change would apply to quota-show and quota-update >> methods. >> >> This approach will help to simplify the >> implementation of another blueprint named >> per-flavor-quotas >> >> Feedback? Suggestions? >> >> >> Sergio Juan Cazzolato >> Intel Software Argentina >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__ >> cgi-bin/mailman/listinfo/__openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev> >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev> >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev> >> >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev >> >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev> >> >> >> The reverted series for nova on master is here [1]. >> >> >> I don't think we want a full revert here, the feature that we broke is >> the ability to easily update the default quota values without restarting >> any services, not quota-classes themselves. Given that I see 3 paths >> forward: >> >> 1. Provide an alternate way to do this. OpenStack already has an >> implicit assumption that one has a way of rolling out config files >> across all machines. so we can teach oslo.config to know which config >> options can be updated without a restart. While this definitely breaks >> the API, this is a rarely used API and we can avoid breaking >> functionality at least. >> 2. Do a partial revert of this API to only support overriding the >> default quota values. Hopefully while doing this we can simplify the >> quota logic and reduce the number of DB calls needed. This way we can >> restore the working part of the API and not the unimplemented >> quota-class logic itself. >> 3. Do a full revert and re-add all the unimplemented quota-class logic, >> we now have just re-added a non-working API. >> >> While I would prefer to take path 1 as I think that gets us closer to >> where we should be, I think path 2 is safer approach. >> >> >> Once that's merged I can work on backporting the revert for the API >> change to stable/icehouse, which will be a little tricky given >> conflicts from master. >> >> [1] >> https://review.openstack.org/#__/q/status:open+project:__ >> openstack/nova+branch:master+__topic:restore-quota-class,n,z >> >> <https://review.openstack.org/#/q/status:open+project: >> openstack/nova+branch:master+topic:restore-quota-class,n,z> >> >> -- >> >> Thanks, >> >> Matt Riedemann >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > The full revert, #3 in your list, is half merged. We talked about this in > the nova meeting on Thursday [1] and this was the agreed direction given > Icehouse is broken if you're upgrading and using this API. So the > immediate concern is getting Icehouse fixed, which means reverting the back > to the point that the API is available again on master and then cherry > picking that back to stable/icehouse so anyone upgrading to Icehouse isn't > broken. > > I agree that we don't want all of this unusable code in tree and we should > work on ripping out what isn't needed in Juno, maybe that involves > deprecating part of the existing API, I'm not sure since it seems with the > V2 API discussions we came to the conclusion that we can't ever remove > anything from V2. However, I think we have to slow down and figure that > out separately in Juno rather than leave Icehouse broken until we figure > out what we're going to do on master and then backport it. > Matt and I chatted on IRC and have come up with an outlined plan, if we missed anything please don't hesitate to comment or ask. https://etherpad.openstack.org/p/quota-classes-goof-up > > [1] http://eavesdrop.openstack.org/meetings/nova/2014/nova. > 2014-05-29-14.01.log.html > > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
