Should translate Unauthorized NeutronClientException in allocate_for_instance
Bug #1298075 reported by
Matt Riedemann
This bug report is a duplicate of:
Bug #1571722: Neutronclient failures throw unhelpful "Unexpected Exception".
Edit
Remove
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Low
|
Unassigned |
Bug Description
If your auth token expires while allocating the network for an instance with the neutronv2 API in nova, you'll get a 500 from the server because the Unauthorized neutron client exception isn't handled and translated to a more specific NovaException (expecting a 401 in this case). Paste here:
http://
We could decorate allocate_
Changed in nova: | |
assignee: | nobody → Matt Riedemann (mriedem) |
tags: | added: neutron |
Changed in nova: | |
assignee: | nobody → Brent Eagles (beagles) |
Changed in nova: | |
status: | Triaged → Confirmed |
assignee: | Brent Eagles (beagles) → nobody |
To post a comment you must log in.
Discussed a bit with Aaron Rosen:
(4:29:00 PM) mriedem: arosen: quick question since i have to leave quick, but thinking about decorating nova.network. neturonv2. api.allocate_ for_instance with something that would translate an Unauthorized( NeutronClientEx ception) to something more specific as a NovaException, rather than getting a 500, /review. openstack. org/#/q/ status: open+project: openstack/ nova+branch: stable/ havana+ topic:backport- neutron- auth-fixes, n,z /github. com/openstack/ neutron/ blob/master/ neutron/ notifiers/ nova.py# L46
(4:29:04 PM) mriedem: do you see any issues with that?
(4:29:29 PM) mriedem: arosen: in case the token passed to create the neutron client expires while doing the network allocation
(4:32:04 PM) arosen: mriedem: hrm to me it seems like if that happens the client should be able to handle that and get a new one ? no?
(4:32:26 PM) mriedem: arosen: we don't pass the password to the client to get a new token
(4:32:47 PM) arosen: just the existing token if we have one?
(4:32:51 PM) mriedem: yup
(4:33:01 PM) mriedem: arosen: goes back to this: https:/
(4:33:11 PM) arosen: yup i remember
(4:33:40 PM) arosen: mriedem: hrm so one thing i'm thinking in my neutron-nova-event patch i made neutron use the service_tenant_id instead of username/password
(4:33:49 PM) arosen: that way i don't have to deal with tokens and keystone at all
(4:34:01 PM) arosen: I wonder if we should be doing that here as well?
(4:34:33 PM) arosen: or perhaps i shouldn't be doing that in neutron but it gets the token stuff out of the picture i believe
(4:34:53 PM) mriedem: arosen: but the neutron/nova event stuff still has config options for nova user/password right?
(4:35:26 PM) mriedem: arosen: but it'd be nice to get tokens out of the picture here
(4:35:31 PM) arosen: mriedem: right it does. Perhaps it does get tokens as well. :/
(4:35:33 PM) arosen: https:/
(4:35:34 PM) mriedem: since there is always going to be a window of failure
(4:35:49 PM) arosen: i agree.
(4:35:59 PM) arosen: and having to deal with that failure out of the client kind of sucks :/
(4:36:12 PM) ***arosen or makes it harder
(4:37:59 PM) arosen: mriedem: I think another option might be to pass the user/pass and the token to the client. Then, the client should use the token and if it gets a expired error then it can internally get a new token
(4:38:21 PM) arosen: though i'm not sure that's the right way because in that case we'd need to pass the token back to nova again so we don't keep getting a new one each time.
(4:38:29 PM) mriedem: arosen: so i tried that back in grizzly and it was rejected as being too brute force
(4:38:34 PM) mriedem: right
(4:38:46 PM) arosen: could be passed by via the param dict passed in though :)
(4:38:53 PM) arosen: but yea that's kinda messy i agree.