>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.gord...@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
<mrie...@linux.vnet.ibm.com <mailto:mrie...@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
<mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>
<mailto:mrie...@linux.vnet.ibm.com
<mailto:mrie...@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.cazzol...@intel.com
<mailto:sergio.j.cazzol...@intel.com>
<mailto:sergio.j.cazzol...@intel.com
<mailto:sergio.j.cazzol...@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:vishvana...@gmail.com <mailto:vishvana...@gmail.com>
<mailto:vishvana...@gmail.com
<mailto:vishvana...@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....@hp.com <mailto:philip....@hp.com>
<mailto:philip....@hp.com
<mailto:philip....@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.cazzol...@intel.com
<mailto:sergio.j.cazzol...@intel.com>
<mailto:sergio.j.cazzol...@intel.com
<mailto:sergio.j.cazzol...@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.__org>
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.__org>
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.__org>
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.__org>
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.__org
<mailto:OpenStack-dev@lists.openstack.__org>
<mailto:OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
