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.

[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

Reply via email to