[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