Earlier  
Posted Nick Remark
#openstack-nova - 2019-05-21
13:54:04 boxiang_ ok, thanks :)
13:54:43 alex_xu boxiang_: another patch I have is want to remove something https://review.opendev.org/659243, if that makes sense, probably can save some of your code
13:54:50 alex_xu but still waiting for review
13:59:05 boxiang_ alex_xu: got it. I will read it later.
13:59:41 mriedem1 alex_xu: that removal change of yours would make this not work i think https://review.opendev.org/#/c/650376/
14:00:08 alex_xu mriedem1: emm...let me check that patch
14:00:41 mriedem1 i'm trying to use requested_destination in the rebuild + new image scenario, rather than force_hosts/force_nodes
14:00:45 mriedem1 which requires a hack in the host manager code
14:01:20 mriedem1 i haven't gone over https://review.opendev.org/#/c/645520/ but i would expect it to use requested_destination as well
14:01:57 efried mriedem1 fwiw I've been having similar concerns, which is why I have been procrastinating on that patch.
14:02:34 alex_xu mriedem1: ok, i can have look at it tomorrow, it sounds a complex thing I don't want to go through before sleep
14:02:51 mriedem1 yup understood, i'd comment on the review but
14:03:10 alex_xu efried: nice instinct~
14:04:33 boxiang_ one question.if my patch is something different from the approved spec. Can I update the spec again?
14:04:44 mriedem1 efried: the sriov bp in the top runway slot is expired by a few days https://etherpad.openstack.org/p/nova-runways-train
14:04:52 mriedem1 boxiang_: you can amend the spec yes
14:05:29 mriedem1 sean-k-mooney: adrianc: was a patch ever pushed to update these docs for sriov live migration? https://docs.openstack.org/neutron/latest/admin/config-sriov.html#known-limitations
14:06:07 sean-k-mooney mriedem1: no but its on my todolist for today. im currently updating the osc evacuate command patch
14:06:36 sean-k-mooney mriedem1: you can kick the sriov bp out of the runway and replace it with something else
14:07:20 mriedem1 sean-k-mooney: note that https://review.opendev.org/#/c/647733/ is next in the queue but is in merge conflict
14:07:45 sean-k-mooney oh i guess i need to rebase that too
14:07:46 mriedem brb
14:07:47 boxiang_ mriedem1: ok. i see
14:07:57 sean-k-mooney ok ill do that then the docs patch
14:08:07 efried sean-k-mooney: I'll put it in the slot.
14:11:44 sean-k-mooney looks like teh confligt was just in the nova object version file so i should have a rebased version up shortly
14:12:59 efried aspiers: bottom SEV patches are merging, if you want to get those other rebases working.
14:14:36 dansmith efried: are you holding off on the ironic power state one for ironic side review or something? AFAICT, of the nova people who have looked at it, all are either +vote or out at the moment
14:15:01 efried dansmith: Yes, giving SMEs and people with prior reviews a chance to re-ack.
14:15:07 efried Is there some hurry to merge the spec?
14:15:43 efried dansmith: whoops, I actually asked jroll and melwitt to re-look, but I did it in the -placement channel by accident.
14:16:00 dansmith efried: we've been kinda dragging our feet with it and tssurya has been her usual overly polite self.. we discussed in a couple small groups at ptg about it so I just don't want her to continue to have to wait
14:16:07 dansmith efried: okay
14:16:42 jroll I'm +1 on it
14:16:49 efried dansmith: afaict the code patch isn't being held up by the bp approval https://review.opendev.org/#/c/645611/
14:16:52 sean-k-mooney i have to admit i kind of like running the nova unit tests on my desktop/server
14:17:37 dansmith efried: ...
14:17:41 openstackgerrit sean mooney proposed openstack/nova master: extend libvirt video model support https://review.opendev.org/647733
14:23:29 sean-k-mooney i will redeploy with ^ later today but the unit and functional test pass locally
14:23:58 sean-k-mooney has anyone used rtox https://pypi.org/project/rtox/ by the way
14:31:37 mriedem low-hanging-fruit bug if someone wants it https://bugs.launchpad.net/nova/+bug/1829877
14:31:38 openstack Launchpad bug 1829877 in OpenStack Compute (nova) "avoid lazy-lodaing instance.flavor during cold migration" [Low,Confirmed]
14:31:43 mriedem ooo typo
14:33:33 dansmith efried: tomorrow, the top patch set will have been up for 14 days.. presumably that's plenty of time time for anyone to have voiced their opinion, right?
14:34:03 efried dansmith: "top patch set" of what?
14:34:48 dansmith efried: the latest revision of the ironic power state change. Just trying to figure out what "a few days" means in terms of when we should set reminders to make sure that it gets merged and doesn't get ignored again
14:35:52 efried dansmith: Give it a couple hours for melwitt to come on the scene and pick up the IRC nag I left for her. I expect we can merge it by lunchtime.
14:36:06 dansmith alright
14:38:49 efried tssurya: Meanwhile, you should feel pretty confident this is going to go substantially as it stands, if you have the time and desire to crank on the code some :)
14:57:57 mriedem hmm, scatter_gather_all_cells seems to make us lose the request_id on the context we're using
14:59:54 mriedem which makes debugging not so nice
15:04:54 mriedem the RequestContext.from_dict(context.to_dict()) stuff must overwrite the thread local context
15:05:08 mriedem which messes up the logging, even though those copies should be using the same request id
15:06:36 dansmith mriedem: is it just that the threads we spawn to do the scatter don't get the thread-local set to their new context?
15:10:14 mriedem RequestContext __init__ defaults overwrite=True so i'd think each one is updated
15:10:48 mriedem i'm tracing a cold migration in these logs http://logs.openstack.org/56/656656/12/check/nova-multi-cell/6a403ba/controller/logs/screen-n-super-cond.txt.gz#_May_16_19_46_23_815726 with req-bde576dc-5de2-4113-982d-025c65b97e8d which is the request starting in the API
15:11:01 mriedem but after that we hit the scatter/gather and lose the request id
15:11:28 mriedem after that it's using req-66d8138a-530a-4dec-b1cd-9c22e4402dd1
15:19:48 aspiers efried: yup thanks
15:31:38 kashyap` efried: This was re-proposed (despite me abandoning it): https://review.opendev.org/#/c/660271/ ("Re-propose the spec to allow specifying a list of CPU models")
15:31:52 efried I noticed that
15:31:55 efried haven't looked yet
15:32:09 kashyap` efried: Don't. After technical discussions w/ the libvirt / QEMU CPU modelling maintainers, we've concluded it's not a good idea
15:32:14 kashyap` At least not in its present form.
15:32:33 efried kashyap`: lmk if you want me to -2 bomb the sucker.
15:32:41 kashyap` efried: Hehe, please do.
15:32:48 mriedem cfriesen: ^
15:33:00 efried kashyap`: save me finding the one you originally abandoned, got it at your fingertips?
15:33:08 mriedem unrelated, it seems odd that we'd fail to stop a libvirt cirros guest after a minute http://logs.openstack.org/56/656656/12/check/nova-multi-cell/6a403ba/compute1/logs/screen-n-cpu.txt.gz#_May_16_19_47_26_017509
15:33:10 kashyap` (It was approved previously during Stein-time; but I didn't pay sufficient attention to it.)
15:33:12 efried nm, see the link in the comment.
15:33:48 kashyap` mriedem: Noticed it only today?
15:34:35 mriedem noticed yes, but http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Instance%20failed%20to%20shutdown%20in%2060%20seconds.%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d
15:34:40 efried kashyap`: I did one better, I abandoned it.
15:35:24 mriedem if we're burning up to a minute waiting to gracefully kill cirros guests in the gate that could explain in part why some jobs/tests are really slow
15:35:43 kashyap` efried: Thanks!
15:38:51 kashyap` mriedem: "Needs more investigation." (I'm on mobile data in the library; will check tomm early.)
15:40:44 mdbooth efried: https://review.opendev.org/#/admin/groups/540,members Everybody on that list works for RH except Claudiu, John, and Matt. I don't know Claudiu, and I understand mriedem has some administrative difficulties right now :/
15:41:21 mdbooth efried: So the project is entirely dependent on johnthetubaguy to land stable patches.
15:41:28 mriedem no it's not
15:41:36 mriedem https://review.opendev.org/#/admin/groups/530,members
15:41:42 mriedem there is an #openstack-stable channel
15:41:49 mriedem and people like mtreinish
15:42:09 mriedem i'd also say smcginnis but he's in the same boat as me
15:42:10 kashyap` mriedem: Aren't you referring to release managers group?
15:42:17 mdbooth Ok. John and Matt Treinish
15:42:18 kashyap` I think mdbooth is referring to "stable-core"
15:42:34 mriedem nova-stable-maint's parent group is stable-maint-core 
15:42:44 mdbooth kashyap`: Yeah, mriedem was referring to stable-maint-core, who I understand can ack everything
15:43:03 mriedem Alan Pevecalan.pevec@redhat.comChuck Shortchucks@redhat.comFlavio Percocofpercoco@redhat.com so much for that
15:43:16 mdbooth mriedem: Yeah, it's a bit RH loaded :/
15:43:20 mriedem at some point can RH just extend me a job offer and i can switch sides here and start approving all RH stuff?
15:43:47 mdbooth mriedem: You won't be allowed under trifecta rules ;)
15:44:06 cfriesen kashyap: what was the objection by the libvirt/qemu folks? As you recall, the weakness in the current model is that you can only specify a model on the node, and it affects all guests on that node.
15:44:12 aspiers mriedem: not if another Linux distro nabs you first ;-)
15:44:32 mriedem so pressure the foundation to figure out wtf is going on with huawei developers to be able to work on open source
15:45:04 kashyap` cfriesen: I don't know if that's a "weakness" per-se. But the objection was the we'd need more data; and it is finicky, error-prone.
15:45:43 kashyap` cfriesen: They also asked: Do you have data on why _not_ use the default 'host-model' -- that has the important double-advantage in that, it auto-adds the relevant flags
15:46:22 cfriesen kashyap`: host-model can be an issue if you happen to land on a brand new compute node that has more advanced hardware than most of the other nodes
15:46:31 cfriesen kashyap`: makes it hard to live migrate

Earlier   Later