Open Stack

More comments inline.

Salvatore

On 31 July 2015 at 01:47, Kevin Benton <blak111 at gmail.com> wrote:

> 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.
>
>
As quota-update is usually restricted to admin users this should not be a
problem, unless the deployment uses per-service admin users.



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

That spec seems stuck to me. I think the reason is lack of reasons for
raising its priority.


>
> 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?
>>
>
Once you accept that it's not a big deal to do a round trip to keystone,
then we can do whatever we want. If there is value from a API usability
perspective we'll just do that.
If the issue is instead more the CLI UX, I would consider doing resolving
the name (and possibly validating the tenant uuid) in python-neutronclient.

Also, I've checked the docs [1] and [2] and neutron quota-update is not
supposed to accept tenant name - so probably the claim made in the initial
post on this thread did not apply to neutron after all.


>> 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150731/b50ae3df/attachment.html>