Open Stack

The issue is that the Neutron credentials might not have privileges to
resolve the name to a UUID. I suppose we could just fail in that case.

Let's see what happens with the nova spec Salvatore linked.

On Thu, Jul 30, 2015 at 4:33 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> If the quota update resolved the name to a uuid before it updated the
> quota by uuid, I think it would resolve the issues? You'd just have to
> check if keystone was in use, and then do the extra resolve on update. I
> think the rest of the stuff can just remain using uuids?
>
> Thanks,
> Kevin
> ------------------------------
> *From:* Kevin Benton [blak111 at gmail.com]
> *Sent:* Thursday, July 30, 2015 4:22 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
> tenant-name bug
>
> 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.Fox at 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.ext at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150730/bc85d0e4/attachment.html>