Open Stack

I think nested quotas would give the same thing, i.e. you have a parent project for the group and child projects for the users. This would not need user/group quotas but continue with the ‘project owns resources’ approach.

It can be generalised to other use cases like the value add partner or the research experiment working groups (http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html)

Tim

From: Zhipeng Huang <zhipengh512 at gmail.com>
Reply-To: "openstack-sigs at lists.openstack.org" <openstack-sigs at lists.openstack.org>
Date: Wednesday, 7 March 2018 at 17:37
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, openstack-operators <openstack-operators at lists.openstack.org>, "openstack-sigs at lists.openstack.org" <openstack-sigs at lists.openstack.org>
Subject: Re: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library

This is certainly a feature will make Public Cloud providers very happy :)

On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:
Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota.

Is there a per-user/per-group quota in Nova?

Tim

-----Original Message-----
From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, 7 March 2018 at 17:29
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit library


    There was discussion that Nova would deprecate the user quota feature since it really didn't fit well with the 'projects own resources' approach and was little used. At one point, some of the functionality stopped working and was repaired. The use case we had identified goes away if you have 2 level deep nested quotas (and we have now worked around it).

    Tim
    -----Original Message-----
    From: Lance Bragstad <lbragstad at gmail.com<mailto:lbragstad at gmail.com>>
    Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
    Date: Wednesday, 7 March 2018 at 16:51
    To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
    Subject: Re: [openstack-dev] [keystone] [oslo] new unified limit library



        On 03/07/2018 09:31 AM, Chris Friesen wrote:
        > On 03/07/2018 08:58 AM, Lance Bragstad wrote:
        >> Hi all,
        >>
        ]
        >
        > 1) Nova currently supports quotas for a user/group tuple that can be
        > stricter than the overall quotas for that group.  As far as I know no
        > other project supports this.
    ...
        I think the initial implementation of a unified limit pattern is
        targeting limits and quotas for things associated to projects. In the
        future, we can probably expand on the limit information in keystone to
        include user-specific limits, which would be great if nova wants to move
        away from handling that kind of stuff.
        >
        > Chris
        >
        > __________________________________________________________________________
        >
        > OpenStack Development Mailing List (not for usage questions)
        > Unsubscribe:
        > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
        > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com<mailto:huangzhipeng at huawei.com>
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu<mailto:zhipengh at uci.edu>
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180307/17adab9e/attachment.html>