| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-05 | |||
| 10:02:27 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 10:02:50 | openstackgerrit | suzhengwei proposed openstack/nova master: compute_model problem https://review.openstack.org/462897 | |
| 10:04:16 | openstackgerrit | suzhengwei proposed openstack/nova master: compute_model problem https://review.openstack.org/462897 | |
| 10:11:19 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 10:11:19 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Delete existing allocations for move operations or retries https://review.openstack.org/460433 | |
| 10:40:34 | bauzas | cdent: good point on the allocations being deleted when adding new ones | |
| 10:42:14 | cdent | bauzas: It's kind of non-obvious | |
| 10:42:27 | bauzas | cdent: I think that's the main problem | |
| 10:42:34 | bauzas | cdent: maybe we should be explicit ? | |
| 10:43:07 | bauzas | cdent: also, the problem is that if the scheduler doesn't provide a new destination, then we should still have the wrong allocation | |
| 10:43:22 | bauzas | cdent: so, probably something being discussed at the summit | |
| 10:43:22 | cdent | well it depends on how we want things to mean. The way in which it is possible to replace allocations is something that we added in the late rush at the end of newton | |
| 10:43:40 | cdent | I do agree that managing the information explicitly is usually a good idea | |
| 10:58:57 | openstackgerrit | falseuser proposed openstack/nova master: [BugFix] Release the memory quota for video ram when deleting an instance. https://review.openstack.org/456050 | |
| 11:03:40 | openstackgerrit | falseuser proposed openstack/nova master: [BugFix] Release the memory quota for video ram when deleting an instance. https://review.openstack.org/456050 | |
| 11:45:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: remove scality volume driver https://review.openstack.org/449364 | |
| 11:49:20 | ygl | hi all | |
| 11:49:40 | ygl | can anyone explain to me why boot from volume is faster than boot from image ? | |
| 12:07:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Rename qemu_enable_gluster_storage_driver https://review.openstack.org/447091 | |
| 13:23:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [BugFix] Release the memory quota for video ram when deleting an instance. https://review.openstack.org/456050 | |
| 13:47:56 | openstack | Launchpad bug 1657774 in OpenStack Compute (nova) "duplicate for #1656056 Nova does not re-raise 401 Unauthorized received from Neutron for admin users" [Undecided,In progress] - Assigned to Roman Podoliaka (rpodolyaka) | |
| 13:47:56 | dansmith | mriedem: you opened this bug: https://bugs.launchpad.net/nova/+bug/1656056 | |
| 13:48:06 | openstack | Launchpad bug 1657774 in OpenStack Compute (nova) "Nova does not re-raise 401 Unauthorized received from Neutron for admin users" [Undecided,In progress] - Assigned to Roman Podoliaka (rpodolyaka) | |
| 13:48:06 | dansmith | mriedem: which was marked as a dupe of: https://bugs.launchpad.net/nova/+bug/1657774 | |
| 13:48:19 | dansmith | which has a pending change: https://review.openstack.org/#/c/422696 | |
| 13:48:32 | mriedem | and you have a customer that needs it fixed *today* | |
| 13:48:38 | dansmith | I'm not sure I grok what is going on | |
| 13:48:39 | dansmith | no | |
| 13:48:51 | mriedem | i thought sahid "fixed" this awhile ago | |
| 13:48:54 | dansmith | is the problem token expiry or something? | |
| 13:49:00 | dansmith | yeah, I remember that | |
| 13:49:08 | dansmith | that was before your bug was filed though | |
| 13:49:49 | dansmith | sahid's thing was token expiration during the operation I think | |
| 13:49:56 | mriedem | well, | |
| 13:50:10 | mriedem | there was also a general non-useful error if you configured the neutron creds in nova.conf incorrectly i think | |
| 13:50:16 | mriedem | there was an old bug for that from a long time ago | |
| 13:50:22 | openstack | Launchpad bug 1657774 in OpenStack Compute (nova) "duplicate for #1656056 Nova does not re-raise 401 Unauthorized received from Neutron for admin users" [Undecided,In progress] - Assigned to Roman Podoliaka (rpodolyaka) | |
| 13:50:22 | mriedem | https://bugs.launchpad.net/nova/+bug/1656056 was from something i saw in gate runs | |
| 13:50:27 | mriedem | i did some investigation but didn't dupe it myself | |
| 13:50:35 | mriedem | i couldn't figure out what was going on at the time when i was triaging it | |
| 13:50:51 | dansmith | so the commit message makes it sound like something where we don't raise 401 if the token is an admin, even if we didn't get it from the nova.conf ? | |
| 13:50:57 | lbragstad | if the token is being expired during the operation i can take a poke at it - we should be able to fix that from a service user perspective if that helps | |
| 13:51:18 | rpodolyaka | dansmith: yeah, that's the case, IIRC | |
| 13:51:20 | mriedem | well, this is why we have the service user token spec | |
| 13:52:00 | rpodolyaka | I saw this on my env on requests done by ceilometer polling agent | |
| 13:52:01 | mriedem | https://blueprints.launchpad.net/nova/+spec/use-service-tokens-pike is for using a service token for long-running operations | |
| 13:52:13 | lbragstad | aha - sure | |
| 13:52:25 | rpodolyaka | basically , ceilometer agent uses one token until it expires | |
| 13:52:36 | rpodolyaka | and instead of getting a proper 401, it gets 500 | |
| 13:52:39 | rpodolyaka | in this corner case | |
| 13:52:40 | lbragstad | we also have an endpoint in keystone that allows users with the service role to validate expired tokens | |
| 13:53:03 | mriedem | rpodolyaka: so this sounds like a side effect of sahid's change? | |
| 13:53:10 | dansmith | rpodolyaka: so we should merge this so we can backport even though the service user thing should fix it? | |
| 13:53:14 | dansmith | well, if it's used properly I guess | |
| 13:53:22 | mriedem | where it's not distinguishing between is_admin on the user context and the admin creds in nova.conf? | |
| 13:53:43 | rpodolyaka | mriedem: yep, this ^ | |
| 13:54:52 | openstackgerrit | sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 13:54:52 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 13:55:01 | rpodolyaka | dansmith: I haven't seen the service user spec :( this seems to be a simple fix - we use it in downstream mitaka | |
| 13:55:12 | rpodolyaka | *easy to backport | |
| 13:55:26 | dansmith | rpodolyaka: yeah, this seems like just a bad assumption made in the when-to-raise code | |
| 13:56:49 | rpodolyaka | yeah, there was two different conditions in two different places | |
| 13:57:00 | rpodolyaka | hopefully `use_service_credentials` now covers it properly in https://review.openstack.org/#/c/422696/3/nova/network/neutronv2/api.py | |
| 13:58:55 | dansmith | the implicit "admin if admin context but no token" thing kinda scares me | |
| 13:59:01 | rpodolyaka | ++ | |
| 13:59:26 | dansmith | actually, I guess that already happens in the code | |
| 13:59:51 | rpodolyaka | in the long term we should probably make sure we always pass admin=True to get_client() explicitly | |
| 13:59:53 | dansmith | I guess the second hunk there is just trying to clean up the logic? | |
| 13:59:58 | dansmith | nothing is actually changed I think | |
| 14:00:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Check if domain is persistent before detaching volume https://review.openstack.org/441204 | |
| 14:02:23 | johnthetubaguy | dansmith: thats refresh network_info I think, admin but no user context | |
| 14:02:38 | johnthetubaguy | (and a few other periodic tasks) | |
| 14:02:41 | dansmith | johnthetubaguy: metadata fetch is the example he gave | |
| 14:03:25 | mriedem | ok i was hazy on that, | |
| 14:03:31 | dansmith | johnthetubaguy: so does that patch seem reasonable? | |
| 14:03:33 | johnthetubaguy | dansmith: true, although I assumed we just used the version cached in the instance for that | |
| 14:03:36 | mriedem | so basically context.get_admin_context() and pass that down | |
| 14:03:41 | mriedem | so it doesn't have a token, | |
| 14:03:42 | dansmith | mriedem: right | |
| 14:03:45 | mriedem | but is_admin=True | |
| 14:03:46 | mriedem | ok | |
| 14:04:54 | johnthetubaguy | I would tempted to have a re-raise_401=True? | |
| 14:04:55 | mriedem | so in the commit message where it says we get the 401 b/c the token is expired, | |
| 14:05:02 | mriedem | if we didn't have a token to begin with, | |
| 14:05:08 | mriedem | is that referring to the token that neutronclient creates? | |
| 14:05:29 | johnthetubaguy | I think its the user token passed into the API, that happens to be admin, but expires by the time we talk to neutron | |
| 14:05:58 | johnthetubaguy | ... now if you enable service token auth (the second token) that whole crazy goes away | |
| 14:06:21 | dansmith | johnthetubaguy: so that callers of this have to pass it to get proper behavior you mean? | |
| 14:06:44 | johnthetubaguy | so, its a configuration option right now, to enable the service token to get sent with any user token | |
| 14:07:12 | johnthetubaguy | (line 159 I guess) | |
| 14:07:39 | mriedem | yeah so no one is using that yet, | |
| 14:07:41 | mriedem | so we can ignore that part, | |
| 14:07:54 | mriedem | i'm also a bit lost where you said "I think its the user token passed into the API, that happens to be admin, but expires by the time we talk to neutron" | |
| 14:08:06 | mriedem | i thought if you did context.get_admin_context() there is no token | |
| 14:08:12 | dansmith | mriedem: correct | |
| 14:08:16 | mriedem | hence the "and not context.auth_token" check | |
| 14:08:24 | johnthetubaguy | oh wait, I kinda hate what this is doing | |
| 14:09:11 | johnthetubaguy | I don't like converting what the user passed in, into our own service token | |
| 14:09:14 | johnthetubaguy | I missed that bit | |
| 14:09:22 | johnthetubaguy | well, miss-read it | |