| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 13:24:16 | smcginnis | savvas: Unfortunately no, having some issues getting it set up at the moment. | |
| 13:24:28 | smcginnis | savvas: I was wondering if you could open a bug to make sure we track this? | |
| 13:24:29 | mriedem | dansmith: i've got super special early morning news, the stable/newton backport of the db creds special characters fix and all changes below it are passing https://review.openstack.org/#/c/466808/ https://review.openstack.org/#/c/420750/ https://review.openstack.org/#/c/420876/ | |
| 13:24:46 | mriedem | including the change for the cell0 db name | |
| 13:24:47 | smcginnis | savvas: I looked through the code quick and it does look like we should be handling None correctly. | |
| 13:25:10 | savvas | I'd be happy to. Where should I report this? | |
| 13:26:16 | sdague | mriedem: did you get my email on the db test case debug? | |
| 13:26:28 | mriedem | sdague: reading now | |
| 13:26:39 | smcginnis | savvas: In the top right corner here: https://bugs.launchpad.net/cinder/+bugs | |
| 13:26:43 | sdague | cell1 is still sqlite | |
| 13:26:47 | sdague | is the tldr | |
| 13:27:54 | mriedem | hmm | |
| 13:28:22 | mriedem | that's got to all be done in a fixture, | |
| 13:28:30 | mriedem | and i'd think we could sub the db engine | |
| 13:29:18 | sdague | yeh, the cell magic switchero fixture is pretty complicated, but it's in there | |
| 13:29:56 | sdague | the real challenge is that because we're running this all in a single process, there was something about the context manager that was "interesting" that melwitt and dansmith worked through | |
| 13:30:52 | mriedem | fwiw i didn't think i was using the main cell database fixture | |
| 13:30:58 | mriedem | that did all the switching stuff | |
| 13:31:18 | mriedem | i was using the SimpleCellFixture, which i'm not sure is right to use, but i thought would be simpler to start | |
| 13:31:27 | sdague | mriedem: no this - https://github.com/openstack/nova/blob/76c2453682a7afa26ff2a7eb825e900af53a61d6/nova/tests/fixtures.py#L363-L532 | |
| 13:31:39 | mriedem | right i didn't tihnk i was using that | |
| 13:31:43 | sdague | right, you aren't | |
| 13:31:51 | sdague | and because of that, it doesn't work | |
| 13:32:03 | sdague | because engine facade is global | |
| 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. | |