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.b...@cern.ch>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 7 March 2018 at 17:29
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@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 <lbrags...@gmail.com>
    Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
    Date: Wednesday, 7 March 2018 at 16:51
    To: "openstack-dev@lists.openstack.org" <openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to