| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 13:36:24 | sdague | to get a version of oslo.context out there that lets us do global request id | |
| 13:37:19 | mriedem | danpawlik: if that doesn't work for windows guests then you should probably point that out as a limitation in the release note | |
| 13:39:53 | danpawlik | mriedem: it works on Windows | |
| 13:40:07 | danpawlik | I checked it on my infra and it works without any problem | |
| 13:41:47 | danpawlik | mriedem: this functionality with vendor_id and fake hyperv id is additional. It normally works on new nvidia drivers | |
| 13:48:26 | mriedem | sdague: questions inline | |
| 13:48:36 | sdague | mriedem: looking | |
| 13:50:10 | sdague | mriedem: I can add a really small test that just looks for our key adds | |
| 13:50:43 | mriedem | we should have something | |
| 13:50:51 | mriedem | i'm also having a hard time seeing what's different in here http://logs.openstack.org/12/467812/1/check/gate-cross-nova-python27-ubuntu-xenial/1aa9e05/console.html#_2017-05-25_03_56_24_617422 | |
| 13:51:23 | mriedem | global_request_id ? | |
| 13:52:22 | sdague | yes | |
| 13:55:20 | mriedem | sdague: is there a reason we don't call super from_dict? like is_admin_project is in the parent class from_dict but not the nova one | |
| 13:55:28 | mriedem | was just looking at https://github.com/openstack/nova/commit/80738df83f4cdd7a3143b157b73d1a9e6b3b2c40 | |
| 13:55:36 | sdague | mriedem: only because legacy, which is totally going to screw us other places | |
| 13:55:45 | mriedem | was just looking at this https://github.com/openstack/nova/blob/master/nova/context.py#L196 | |
| 13:55:55 | sdague | yeh | |
| 13:59:19 | sdague | our context on the other side of the RPC bus actually diverges a lot | |
| 13:59:35 | sdague | ok, let me see about an additional fix here | |
| 14:07:35 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Send out notifications when instance tags changed https://review.openstack.org/459923 | |
| 14:11:49 | efried | jaypipes (hopefully) quick question... | |
| 14:12:02 | efried | jaypipes https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L443-L446 <== does this have a sync issue? | |
| 14:12:42 | efried | jaypipes If multiple clients are doing this at the same time for the same resource provider, that is? | |
| 14:13:11 | efried | jaypipes I guess in this context, since it's in the scheduler, and there's only one of those (right?) that's not possible...? | |
| 14:13:20 | jaypipes | efried: that isn't the scheduler :) | |
| 14:13:26 | jaypipes | efried: common mistake... | |
| 14:13:28 | efried | bah, ignorance | |
| 14:13:33 | jaypipes | efried: that's in the compute resource tracker. | |
| 14:13:46 | jaypipes | efried: which holds the COMPUTE_NODE_SEMAPHORE when that is called. | |
| 14:14:01 | efried | jaypipes Ah, the COMPUTE_NODE_SEMAPHORE. | |
| 14:14:43 | jaypipes | efried: we might consider adding some thread-level locking, though, if that routine would get hit outside of the compute node resource tracker (if, for example, _ensure_resource_provider() were called by some of the new claims routines, but I don't think that's going to be the case) | |
| 14:14:50 | efried | jaypipes Uhm, not finding that. Am I spelling it right? | |
| 14:15:19 | openstackgerrit | Sean Dague proposed openstack/nova master: Have nova.context use super from_context https://review.openstack.org/467995 | |
| 14:15:22 | efried | jaypipes Well, next question would be whether it's kosher for me to take that (big-sounding) semaphore from my compute driver at init. | |
| 14:15:26 | sdague | mriedem: ok, hopefully that's better there | |
| 14:15:30 | jaypipes | efried: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L645 | |
| 14:15:39 | jaypipes | efried: COMPUTE_RESOURCE_SEMAPHORE, sorry | |
| 14:16:36 | efried | jaypipes I guess what I was hoping was that the placement API itself would have internal sync, and some kind of deterministic response if I POST a resource that's already there... | |
| 14:16:53 | efried | Like a 412 response, mebbe | |
| 14:17:03 | jaypipes | efried: it does. | |
| 14:17:23 | mriedem | sdague: ok going to also want dansmith to review this | |
| 14:17:29 | sdague | mriedem: sure | |
| 14:17:34 | jaypipes | efried: there is a unique constraint on resource provider name which will throw a 409. | |
| 14:17:52 | efried | jaypipes Ah, good deal. So I don't have to use that semaphore; I can just catch-and-ignore the 409. | |
| 14:17:53 | jaypipes | efried: and then there is a generation field on the resource provider that is used to catch concurrent updates. | |
| 14:18:02 | jaypipes | efried: look for ConcurrentUpdateDetected in the placement code. | |
| 14:18:30 | efried | jaypipes But of course I don't have to read the placement code to find this out, cause it's documented in the placement API ref, right? | |
| 14:18:49 | jaypipes | efried: you mean like this does already? :) https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L388-L400 | |
| 14:18:52 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 14:19:15 | jaypipes | efried: placement api-ref is ongoing. avolkov is working on that. | |
| 14:19:19 | efried | jaypipes Perfect, thanks. Missed that on my first couple read-throughs ;-) | |
| 14:19:30 | jaypipes | avolkov: can you link efried your api-ref patch series so he can review please? | |
| 14:19:43 | efried | (course I didn't know I was looking for 409, so I forgive myself) | |
| 14:19:46 | jaypipes | efried: I live to serve. | |
| 14:19:52 | efried | (though the comment is eminently helpful) | |
| 14:20:37 | dansmith | mriedem: had to rebase again ^ | |
| 14:20:44 | efried | jaypipes I'm still gonna have to come back atcha when it comes to identifying the shared-ness of my resource; but baby steps. | |
| 14:20:51 | avolkov | efried: jaypipes: https://review.openstack.org/#/c/449765/ | |
| 14:21:03 | mriedem | dansmith: i bet you can do some horse trading with sdague on his context patch | |
| 14:21:24 | jaypipes | efried: resources aren't shared :) resource providers are decorated with the MISC_SHARES_VIA_AGGREGATE trait. | |
| 14:21:39 | avolkov | efried: jaypipes: and built version http://docs-draft.openstack.org/96/467596/2/check/gate-placement-api-ref-nv/7cd3495//placement-api-ref/build/html/ | |
| 14:22:00 | jaypipes | efried: https://review.openstack.org/#/q/topic:cd/placement-api-ref+status:open | |
| 14:22:20 | mriedem | dansmith: the rebase is gone | |
| 14:22:22 | mriedem | *wrong | |
| 14:22:40 | jaypipes | efried: you'll notice we use a similar strategy for most resource creation in the placement client: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L784-L789 | |
| 14:22:43 | mriedem | but thanks for the stat padding | |
| 14:22:58 | mriedem | oh wait | |
| 14:23:04 | mriedem | yeah, | |
| 14:23:05 | mriedem | wrong again | |
| 14:23:44 | efried | avolkov jaypipes Thanks y'all. | |
| 14:24:06 | dansmith | mriedem: okay, I'm doing like six things at once, so I'll look again in a sec | |
| 14:25:30 | danpawlik | mriedem: http://imgur.com/g5Mo9KT | |
| 14:26:49 | jaypipes | dansmith: only six? | |
| 14:27:26 | dansmith | jaypipes: I can only count that high | |
| 14:28:03 | danpawlik | mriedem: I don't have ant problems to install new nvidia drivers if vendor is not set | |
| 14:28:24 | danpawlik | mriedem: I try to install the newest drivers | |
| 14:29:25 | dansmith | mriedem: oh, I don't get why git keeps dropping that removal | |
| 14:29:27 | mriedem | danpawlik: ok | |
| 14:29:46 | mriedem | dansmith: you can blame it on the rain, but you can't blame it on git | |
| 14:29:56 | mriedem | sdague: question/comment in https://review.openstack.org/#/c/467995/ | |
| 14:30:04 | openstackgerrit | Sean Dague proposed openstack/nova master: Migrate to oslo request_id middleware https://review.openstack.org/467998 | |
| 14:30:11 | sdague | mriedem: looking | |
| 14:32:03 | dansmith | mriedem: well, it just drops that hunk without calling it a conflict, so I'll blame it anyway | |
| 14:32:28 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 14:32:37 | dansmith | maybe we could merge this and avoid me chasing rebases | |
| 14:32:49 | sdague | mriedem: answered | |
| 14:33:20 | sdague | the constructor for oslo.context in the from_ methods use the original class | |
| 14:33:24 | mriedem | https://s-media-cache-ak0.pinimg.com/236x/75/c1/dc/75c1dcb4c3ab545deeb1f192eef3c0af.jpg?noindex=1 | |
| 14:33:28 | mriedem | just a bunch of hunks | |
| 14:33:39 | sdague | so that's how we still end up with nova context | |
| 14:33:44 | sdague | after the super call | |
| 14:33:50 | sdague | links in review | |
| 14:34:43 | mriedem | # TODO(sdague): also context has show_deleted, we should | |
| 14:34:46 | mriedem | also or oslo? | |
| 14:35:19 | mriedem | dansmith: i've been your huckleberry for weeks on this one | |
| 14:36:18 | sdague | mriedem: heh, yeh | |
| 14:36:22 | sdague | I can fix the typo | |
| 14:37:36 | openstackgerrit | Sean Dague proposed openstack/nova master: Have nova.context use super from_context https://review.openstack.org/467995 | |
| 14:37:40 | mriedem | alex_xu: jaypipes: re-confirming, but when deleting a service we don't actually delete the compute_nodes record, | |
| 14:37:45 | mriedem | nothing actually deletes the compute_nodes record | |