This is certainly a feature will make Public Cloud providers very happy :) On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell <tim.b...@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.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 > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__________________________________________________________________________ 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
