More comments inline. Salvatore
On 31 July 2015 at 01:47, Kevin Benton <blak...@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....@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 [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> 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 >> >> > > > -- > 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 > >
__________________________________________________________________________ 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
