On Mon, Jun 2, 2014 at 12:29 PM, Matt Riedemann <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>> 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>> 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>]
>>             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>> 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>> 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>
>>                     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
>>                 <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
>>             <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
>>
>>         <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>
>>     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
>> 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
> 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

Reply via email to