[openstack-dev] [nova] nova default quotas

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Jun 17 16:12:33 UTC 2014



On 6/10/2014 3:56 PM, Matt Riedemann wrote:
>
>
> 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/
>

Just an update on progress, the Tempest API test is up for review:

https://review.openstack.org/#/c/100342/

 From a short discussion in the nova channel this week it sounds like 
Chris Behrens also has a possible solution for ripping out the guts of 
the quota_class API so that we can just use the 'default' quota class 
with the existing quotas table and data model, but would require a 
nova-spec.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list