| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-21 | |||
| 12:44:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: Restore connection_info after live migration rollback https://review.opendev.org/660375 | |
| 12:46:36 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Add uuid filter to nova list https://review.opendev.org/660376 | |
| 13:05:02 | alex_xu | sean-k-mooney: good morning, do you want to have look at this https://review.opendev.org/#/c/658716/1/specs/train/approved/show-server-numa-topology.rst@110 ? | |
| 13:05:30 | alex_xu | i guess core and threads should be removed also. | |
| 13:06:08 | efried | thanks for that, kashyap | |
| 13:06:46 | alex_xu | since numa_cell.cpu_topology only valid for dedicated cpu policy, and I guess cores and threads is empty all the time | |
| 13:07:28 | sean-k-mooney | alex_xu im just waiting for someome form the gas company to call but i can take a look in an hour or so | |
| 13:07:58 | alex_xu | sean-k-mooney: thanks, not hurry | |
| 13:11:20 | sean-k-mooney | alex_xu: im ok with the api reporting the number of sockets, cores per socket and threads per core. | |
| 13:11:35 | sean-k-mooney | im not sure it shoudl be reported at the numa node level however | |
| 13:11:43 | sean-k-mooney | given that its vm wide | |
| 13:11:55 | alex_xu | sean-k-mooney: yea, at least not in the numa cell | |
| 13:12:59 | sean-k-mooney | i would add cpu_topology:{sockets:1,cores:10, threads:2} as a sibling but not childe of nodes | |
| 13:13:12 | alex_xu | whether we have separated file for sockets, cores and threads, that should be a question for yonglihe and chris | |
| 13:13:27 | sean-k-mooney | that said i have not really given that much tought | |
| 13:14:40 | alex_xu | sean-k-mooney: I will tell yonglihe, let him check with starlingx whether need sockets, cores and threads | |
| 13:15:07 | openstackgerrit | Merged openstack/nova master: Add infrastructure for invoking libvirt's getDomainCapabilities API https://review.opendev.org/655268 | |
| 13:16:34 | alex_xu | sean-k-mooney: actually, we won't have different hugepage size for cells | |
| 13:17:06 | alex_xu | i'm not sure this one also | |
| 13:18:23 | sean-k-mooney | correct we wont | |
| 13:18:43 | sean-k-mooney | we store the info in the db percell | |
| 13:18:54 | alex_xu | yes | |
| 13:19:06 | sean-k-mooney | but that is just so we did not have to pass it in as a peramater when calulating the assignment | |
| 13:19:29 | sean-k-mooney | but as you said the pagesize will be the same for all cells in the instance | |
| 13:21:16 | sean-k-mooney | libvirt can technically support different page sizes per cell and even multipl page sizes in the same numa cell but we have no plans to ever support that in nova so we dont really need to worry about it | |
| 13:21:41 | alex_xu | yea, can't see a usecase for that | |
| 13:22:27 | alex_xu | if they need that, then put it out of cell also, sounds correct choice | |
| 13:22:57 | sean-k-mooney | yes i think so to. | |
| 13:23:58 | sean-k-mooney | i would prefer to have the vm wide things at the top level and the cell specific things at the node level. whcih i think is your preference too. | |
| 13:24:43 | alex_xu | yes. our db structure is really confuse me in the beginning | |
| 13:25:28 | alex_xu | sean-k-mooney: thanks, I think yonglihe can move forward now | |
| 13:52:11 | efried | kashyap: If you'll ack https://review.opendev.org/#/c/633855/ I'll approve it. | |
| 13:53:10 | efried | tia | |
| 13:53:23 | boxiang_ | alex_xu: hi alex, is it necessary for me to add the approved blueprint to runways again? https://review.opendev.org/#/c/645520/ | |
| 13:53:51 | mriedem | boxiang_: yes | |
| 13:53:54 | mriedem | just queue it back up | |
| 13:53:56 | alex_xu | yea | |
| 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 | |