Good point. Unfortunately the other issues are going to be the hard part to
deal with. I probably shouldn't have brought up performance as a complaint
at this stage. :)

On Thu, Jul 30, 2015 at 3:26 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote:

> Can a non admin update quotas? Quota updates are rare. Performance of them
> can take the hit.
>
> Thanks,
> Kevin
>
> ------------------------------
> *From:* Kevin Benton
> *Sent:* Wednesday, July 29, 2015 10:44:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
> tenant-name bug
>
> >Dev lessons learned: we need to validate better our inputs and refuse to
> update a tenant-id that does not exist.
>
> This is something that has come up in Neutron discussions before. There
> are two issues here:
> 1. Performance: it will require a round-trip to Keystone on every request.
> 2. If the Neutron keystone user in unprivileged and the request context is
> unprivileged, we might not actually be allowed to tell if the tenant exists.
>
> The first we can deal with, but the second is going to be an issue that we
> might not be able to get around.
>
> How about as a temporary solution, we just confirm that the input is a
> UUID so names don't get used?
>
> On Wed, Jul 29, 2015 at 10:19 PM, Bruno L <teolupus....@gmail.com> wrote:
>
>> This is probably affecting other people as well, so hopefully message
>> will avoid some headaches.
>>
>> [nova,cinder,neutron] will allow you to do a quota-update using the
>> tenant-name (instead of tenant-id). They will also allow you to do a
>> quota-show tenant-name and get the expected values back.
>>
>> Then you go to the tenant and end up surprised that the quotas have not
>> been applied and you can still do things you were not supposed to.
>>
>> It turns out that [nova,cinder,neutron] just created an entry on the
>> quota table, inserting the tenant-name on the tenant-id field.
>>
>> "Surprise, surprise!"
>>
>> Ops lessons learned: use the tenant-id!
>>
>> Dev lessons learned: we need to validate better our inputs and refuse to
>> update a tenant-id that does not exist.
>>
>> I have documented this behaviour on
>> https://bugs.launchpad.net/neutron/+bug/1399065 and
>> https://bugs.launchpad.net/neutron/+bug/1317515. I can reproduce it in
>> IceHouse.
>>
>> Could someone please confirm if this is still the case on master? If not,
>> which version of OpenStack addressed that?
>>
>> Thanks,
>> Bruno
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
__________________________________________________________________________
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