[openstack-dev] [nova] where to expose network quota

Day, Phil philip.day at hp.com
Fri Jan 10 11:15:48 UTC 2014



> -----Original Message-----
> From: Robert Collins [mailto:robertc at robertcollins.net]
> Sent: 10 January 2014 08:54
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] where to expose network quota
> 
> On 8 January 2014 03:01, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> > On Mon, Jan 6, 2014 at 4:47 PM, Yaguang Tang
> > <yaguang.tang at canonical.com>
> ...
> >
> > For the V3 API clients should access neutron directly for quota information.
> > The V3 API will no longer proxy quota related information for neutron.
> > Also novaclient will not get the quota information from neutron, but
> > users should use neutronclient or python-openstackclient instead.
> >
> > The V3 API mode for novaclient will only be accessing Nova - with one
> > big exception for querying glance so images can be specified by name.
> > And longer term I think we need to think about how we share client
> > code amongst clients because I think there will be more cases where
> > its useful to access other servers so things can be specified by name
> > rather than UUID but we don't want to duplicate code in the clients.
> 
> Also I think we shouldn't change v2 for this.
> 
> -Rob
> 
If you mean we shouldn't fix the V2 API to report Neutron quotas (rather that "we shouldn't change the V2 api to remove network quotas) then I disagree  - currently the V2 API contains information on network quotas, and can be used on systems configured for either nova-network or Neutron.   It should provide the same consistent information regardless of the network backend configured - so it's a bug that the V2 API doesn't provide network quotas when using neutron.

I know we want to deprecate the V2 API but it will still be around for a while - and in the meantime if people want to put the effort into working on bug fixes then that should still be allowed.

Phil



More information about the OpenStack-dev mailing list