| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-15 | |||
| 19:21:24 | sean-k-mooney | stephenfin: ya instead of popcorn maybe lyarwood should have grabed wiskey | |
| 19:23:09 | stephenfin | sean-k-mooney: indeed :) | |
| 19:23:10 | stephenfin | meanwhile, mriedem: you'll hate this https://review.openstack.org/#/c/631038/ cfriesen would no doubt be interested too, if he were around | |
| 19:27:34 | mriedem | commented | |
| 19:38:39 | openstackgerrit | Merged openstack/nova stable/rocky: Add links to summit videos in user/cells.rst https://review.openstack.org/627019 | |
| 19:53:27 | sean-k-mooney | a nice simple change for people to review https://review.openstack.org/#/c/573066/10 | |
| 19:54:15 | sean-k-mooney | that said i guess we are still waiting on zuul | |
| 20:10:54 | lyarwood | sean-k-mooney: all brexit related donations of whiskey welcome in the coming days ;) | |
| 20:13:41 | openstackgerrit | Jack Ding proposed openstack/nova master: [WIP] Flavor extra spec and image properties validation https://review.openstack.org/620706 | |
| 20:21:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695 | |
| 20:21:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677 | |
| 20:21:17 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042 | |
| 20:21:17 | openstackgerrit | Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705 | |
| 20:21:18 | openstackgerrit | Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711 | |
| 20:21:18 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049 | |
| 20:21:35 | efried | jaypipes, cdent, mriedem: Thanks for the reviews, these should be ready now ^^^ | |
| 20:23:19 | jaypipes | efried: np. will re-review tomorrow morn. | |
| 20:36:51 | efried | jaypipes: Thanks. | |
| 20:46:16 | cdent | thanks efried I'll also look tomorrow | |
| 20:46:36 | efried | cdent: Are you on your way out, or can you help me understand https://review.openstack.org/#/c/630745/ quick? | |
| 20:46:51 | cdent | I can look | |
| 20:47:05 | cdent | efried: what's the confusion? | |
| 20:47:24 | efried | first, the commit message makes it sound like there would be a conflict between zuul and tox somehow. I thought each ignored the other. | |
| 20:48:10 | cdent | the tox-siblings functionality used by zuul only works if the tox name and the tox env have he same name, becuse it does some digging around in the tox directory | |
| 20:48:30 | cdent | that was discussed in the change which extracted placement: | |
| 20:48:47 | cdent | (the functional test changes for that, I mean): | |
| 20:48:58 | efried | methinks stephenfin ought to be a reviewer on this patch... | |
| 20:49:17 | cdent | https://review.openstack.org/#/c/617941/ | |
| 20:49:32 | cdent | efried: it's literally: make functional-py37 the same as py36 | |
| 20:49:35 | cdent | py36 already works | |
| 20:49:38 | cdent | py37 does not | |
| 20:49:55 | cdent | py37 was merged at the same time as the placement external fixture stuff | |
| 20:50:13 | efried | cdent: So yeah, that was #2: would the problem be exposed by changing .zuul.yaml to add the py37 job, then prove this "fixes" it by rebasing that change on this one? | |
| 20:50:13 | cdent | it's just a merge conflict that didn't get caught because we don't do functional-py37 in the gate | |
| 20:50:56 | cdent | I didn't want to add the functional-py37 job becuase there isn't consensus to have that in nova yet, and mdbooth already confirmed it by hand | |
| 20:51:27 | efried | Okay. #3, is there (or should there be) a bug about this? | |
| 20:51:35 | cdent | #3: meh | |
| 20:51:56 | cdent | isn't that just overhead, especially since functional-py37 is a nice to have, not a thing we do in the gate that is impacting many | |
| 20:52:06 | cdent | it only showed up because mdbooth encountered some troubles | |
| 20:52:12 | cdent | why not just fix it and get it over with? | |
| 20:52:51 | efried | wfm, just ticking the boxes. | |
| 21:28:04 | melwitt | efried: came across this bug which has something to do with Power8. would you mind taking a look and commenting if any of it makes sense to you? https://bugs.launchpad.net/nova/+bug/1776929 | |
| 21:28:06 | openstack | Launchpad bug 1776929 in OpenStack Compute (nova) "Web Console for Power8 KVM guest sends mouse events to guest mouse instead of guest tablet?" [Undecided,New] | |
| 21:28:35 | efried | melwitt: Neat. We should talk to somebody at IBM about that. mmedvede? | |
| 21:29:11 | efried | melwitt: Even when I worked for IBM (lo those many days ago) I never knew squat about power *k*vm. | |
| 21:30:03 | mmedvede | efried: hehe, I'll take a look. I'll probably need to find someone who is more knowledgeable about this than me | |
| 21:30:24 | melwitt | ok. I don't know anything about power or power kvm so just looking for someone who knows more than me to help triage | |
| 21:30:30 | efried | mmedvede: I'm counting on six degrees here. For sure you'd be one degree closer than me. | |
| 21:30:31 | melwitt | thanks mmedvede | |
| 21:30:49 | efried | melwitt: you, me, mmedvede - three degrees to go. | |
| 21:37:37 | efried | #save | |
| 21:37:49 | efried | damn | |
| 21:42:51 | melwitt | mriedem: reading through your comments. when I said "returns 500" for the server create, I meant via the server fault message. correct that the API returns 202 | |
| 21:44:39 | mriedem | ok i read that as 500 response | |
| 21:45:29 | melwitt | yeah, I know. it needs more context to be clear | |
| 21:45:47 | melwitt | meaning the comment needs to be better or different | |
| 21:46:41 | mriedem | some of my other comments are musing on side effects of this that could break other things, like rebuild/evacuate/unshelve, but that doesn't necessarily mean you need to change anything | |
| 21:46:56 | mriedem | if the operator f*s you by dropping the limit and then you rebuild and blow up, that's on the operator | |
| 21:49:27 | melwitt | yeah | |
| 21:51:17 | melwitt | I'll go through the comments in detail and add to the patch to have more information where you've pointed out | |
| 21:54:49 | mriedem | melwitt: were you going to abandon https://review.openstack.org/#/c/624832/ ? | |
| 21:55:18 | melwitt | mriedem: yeah. wanted to wait for feedback before doing. sounds like it's clear to abandon now | |
| 21:55:32 | mriedem | yeah i think what you have in the last patch in the series would be sufficient | |
| 21:55:50 | mriedem | thinking about that, you could work that as an assertion wrinkle into the functional test for bfv | |
| 21:55:56 | mriedem | assert that too many devices is in the fault | |
| 21:56:12 | melwitt | I thought I did already. /me looks again | |
| 21:56:17 | mriedem | yeah you did, nvm | |
| 21:56:19 | mriedem | just looked again | |
| 21:57:14 | melwitt | k | |
| 22:30:53 | mriedem | dansmith: random question: you know how the context loses it's cell targeting when it goes over rpc, and then in conductor methods like unshelve_instance we have the targets_cell decorator to re-target the context based on the instance - what happens with the instance._context that is also originally targeted to the cell when the instance is retrieved in the API and it goes over rpc? | |
| 22:30:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677 | |
| 22:30:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705 | |
| 22:30:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695 | |
| 22:30:59 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049 | |
| 22:30:59 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042 | |
| 22:31:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711 | |
| 22:31:10 | mriedem | does that retain the targeting? because i don't see is re-targeting the instance._context, but yet instance.save() works | |
| 22:31:16 | mriedem | *us | |
| 22:32:24 | dansmith | mriedem: the _context for the objects doesn't go over rpc either, if that's what you're asking | |
| 22:32:40 | dansmith | mriedem: you get a new context on de-serialize from whatever context was used for the rpc call | |
| 22:34:50 | mriedem | ok i'm lost on where that happens | |
| 22:34:54 | mriedem | for the instance._context i mean | |
| 22:35:18 | dansmith | where the _context gets rebuilt on deserialize? | |
| 22:35:22 | mriedem | yeah | |
| 22:35:36 | dansmith | it's deep, probably in ovo, but I can look | |
| 22:35:41 | dansmith | either way.. why? | |
| 22:35:51 | dansmith | I fear these questions come from a readiness to abuse something :) | |
| 22:36:24 | mriedem | because i was rebasing and looking at this again https://review.openstack.org/#/c/627890/2/nova/compute/manager.py@5990 where i'm sending an instance and context, targeted at the source cell, to a host in the target cell | |
| 22:36:27 | mriedem | and that won't work | |
| 22:36:57 | mriedem | i know about targets_cell to retarget the context in the conductor methods, but am wondering where the instance._context is re-targeted so it can continue to do things like instance.save() in conductor | |
| 22:37:03 | mriedem | and have those changes go back to the source cell db | |
| 22:37:43 | dansmith | it won't be re-targeted, it will be un-targeted | |
| 22:37:47 | mriedem | because of the cheating serializer in our tests, chances are i'll be writing a lot of code before i really find out in test if i'm screwing something up fundamental here | |
| 22:38:41 | mriedem | ok so if instance._context is untargeted, and you unshelve, which is in superconductor and presumably is configured for [database]/connection = cell0, where are those instance.save() updates going? | |
| 22:38:41 | dansmith | mriedem: the rpc layer calls, via the serializer and _process_object(), the obj_from_primitive, which does: https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L392 | |
| 22:39:13 | dansmith | mriedem: they'd try to go to cell0 and just fail because save() can't find the instance to update | |
| 22:39:46 | mriedem | i'm not sure how tempest isn't blowing up then | |
| 22:40:32 | dansmith | surely because we run through an @targets_cell somewhere yeah? | |
| 22:41:32 | mriedem | ComputeTaskManager.unshelve_instance in conductor has targets_cell yeah | |
| 22:41:44 | mriedem | so that hits before we deserialize? | |