| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 13:32:05 | mriedem | huh, i thought SimpleCellFixture would take care of things | |
| 13:32:18 | danpawlik | Morning | |
| 13:32:39 | mriedem | this one https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/tests/fixtures.py#L257 | |
| 13:32:40 | sdague | I'm pretty sure that stopped working once there was the context manager calls | |
| 13:33:26 | mriedem | https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/tests/fixtures.py#L328 ? | |
| 13:33:27 | sdague | https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/compute/api.py#L2401 is basically where it goes off the rails | |
| 13:33:58 | mriedem | that shouldn't actually do anything https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/tests/fixtures.py#L296 | |
| 13:34:15 | sdague | the inst_map.cell_mapping is | |
| 13:34:16 | sdague | CellMapping(created_at=None,database_connection='sqlite:///',id=1,name='onlycell',transport_url='fake://nowhere/',updated_at=None,uuid=1d5950cd-863a-4eb6-a3ec-3583fc93fbfc) | |
| 13:34:34 | mriedem | sdague: yeah i think because of this https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/tests/fixtures.py#L328 | |
| 13:34:46 | mriedem | i think SingleCellSimple is too simple here | |
| 13:34:52 | mriedem | and why i wasn't sure it would work | |
| 13:34:54 | mriedem | so that confirms it | |
| 13:34:56 | sdague | yeh | |
| 13:35:17 | mriedem | well, i think i can add the cell1 mapping manually | |
| 13:35:24 | mriedem | we have the api db setup | |
| 13:35:26 | sdague | so, I guess the question is if you can pull that from your config | |
| 13:35:31 | sdague | yeh | |
| 13:35:39 | danpawlik | mriedem: Please check my PS https://review.openstack.org/#/c/459753/ . Thanks! | |
| 13:35:45 | mriedem | i think i just create the main cell db, and use that url for the cell1 mapping db connection | |
| 13:35:49 | sdague | mriedem: ok, but before you dive in there | |
| 13:36:09 | sdague | we need to delete some overly agressive context unit tests - https://review.openstack.org/#/c/467995/ | |
| 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 | |