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 [blak...@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....@pnnl.gov<mailto: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<mailto: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://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://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
