[openstack-dev] [nova] nova default quotas
Matt Riedemann
mriedem at linux.vnet.ibm.com
Tue Jun 10 20:56:34 UTC 2014
On 6/4/2014 11:02 AM, Day, Phil wrote:
> >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
>
> I added a few thoughts / questions
>
> *From:*Joe Gordon [mailto:joe.gordon0 at gmail.com]
> *Sent:* 02 June 2014 21:52
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova] nova default quotas
>
> On Mon, Jun 2, 2014 at 12:29 PM, Matt Riedemann
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>
>
>
> On 6/2/2014 12:53 PM, Joe Gordon wrote:
>
>
>
>
> On Thu, May 29, 2014 at 10:46 AM, Matt Riedemann
>
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>
> <mailto:mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>>> 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
> <sergio.j.cazzolato at intel.com
> <mailto:sergio.j.cazzolato at intel.com>
>
> <mailto:sergio.j.cazzolato at intel.com
> <mailto:sergio.j.cazzolato at intel.com>>> 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:vishvananda at gmail.com <mailto:vishvananda at gmail.com>
> <mailto:vishvananda at gmail.com
> <mailto:vishvananda at gmail.com>>]
> 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
> <philip.day at hp.com <mailto:philip.day at hp.com>
>
> <mailto:philip.day at hp.com
> <mailto:philip.day at hp.com>>> 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
> <sergio.j.cazzolato at intel.com
> <mailto:sergio.j.cazzolato at intel.com>
>
> <mailto:sergio.j.cazzolato at intel.com
> <mailto:sergio.j.cazzolato at intel.com>>> 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
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.__org>
> <mailto:OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.__org>
> <mailto:OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.__org>
> <mailto:OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.__org>
> <mailto:OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>>
> 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
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.__org>
> <mailto:OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> 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
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
The reverts are all merged on master for Juno and the stable/icehouse
revert of the API removal is available for review [1].
[1] https://review.openstack.org/#/c/99207/
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list