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 <[email protected]> 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 [[email protected]] > *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 <[email protected]> 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 <[email protected]> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Kevin Benton >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
