| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-15 | |||
| 13:02:58 | brinzhang | if I want to use auto, how to config? | |
| 13:03:04 | sean-k-mooney | https://github.com/openstack/nova/blob/stable/rocky/nova/conf/upgrade_levels.py | |
| 13:03:10 | sean-k-mooney | but also that is the file you want | |
| 13:03:37 | sean-k-mooney | the default is unest which means use the latest vers this code knows | |
| 13:03:46 | sean-k-mooney | https://github.com/openstack/nova/blob/stable/rocky/nova/conf/upgrade_levels.py#L55-L61 | |
| 13:04:35 | sean-k-mooney | [upgrade_level]/compute=auto | |
| 13:04:51 | brinzhang | got it, thanks | |
| 13:04:56 | sean-k-mooney | in this case you want 5.1 | |
| 13:05:04 | sean-k-mooney | so you can just set that | |
| 13:05:21 | sean-k-mooney | you also need to do it for the conductor | |
| 13:05:30 | sean-k-mooney | https://github.com/openstack/nova/blob/stable/rocky/nova/conf/upgrade_levels.py#L117 | |
| 13:05:51 | brinzhang | yeah, I will try, two ways: 1. set [upgrade_level]/compute=auto in nova compute node, and then to do live migration, | |
| 13:06:07 | sean-k-mooney | you need to set it for both compute and conductor | |
| 13:06:13 | brinzhang | 2. replaced all nodes's code of nova, and then try again | |
| 13:06:25 | brinzhang | ack | |
| 13:06:43 | sean-k-mooney | i assume you have also backported all the ovo changes | |
| 13:07:10 | sean-k-mooney | e.g. the change to the migrate_data object to store the numa toplogy | |
| 13:08:15 | brinzhang | yes, I was backported all the bp's patches | |
| 13:08:48 | sean-k-mooney | there have been some bugfixes too but it more or less shoudl be fine | |
| 13:09:04 | sean-k-mooney | brinzhang: you are aware you can manually live migrate numa instance before too right | |
| 13:09:12 | sean-k-mooney | we just dont recaluate the xml | |
| 13:09:31 | sean-k-mooney | so if you have 1 free compute node you can live mgirate without thse backports to do a rolling upgrade | |
| 13:10:10 | sean-k-mooney | you just need to ensure the cpus and hugepages exctra are free on the dest | |
| 13:10:27 | brinzhang | yes | |
| 13:11:40 | brinzhang | I will use two node to have a test, at leat two node, because I should ensure this feature is fine, otherwise, it will have some risk, it's not allow | |
| 13:12:33 | brinzhang | Later I will search for related bug fixes and backport | |
| 13:13:00 | sean-k-mooney | have you also backported sriov live migration i assume not | |
| 13:13:55 | brinzhang | sriov live migration we completed it by ourself, dont need to backport ^^ | |
| 13:14:34 | brinzhang | If we upgrade in future, and we will use the merged codes too | |
| 13:14:45 | sean-k-mooney | the reason i bring that up is numa migratio nmerged after sriov and at least 1 of the patches in the numa serises is adding compatiablty with sriov live migrfation | |
| 13:15:07 | sean-k-mooney | your going from rocky to train right | |
| 13:15:19 | brinzhang | yes, it contained, I was found your point | |
| 13:15:38 | sean-k-mooney | train is the verssion that had both so once your on train you shoudl be fine | |
| 13:15:41 | brinzhang | maybe from rocky to ussuri | |
| 13:16:27 | brinzhang | because we also want to use the pmem feature too ^ | |
| 13:17:16 | brinzhang | sean-k-mooney: thanks for your help | |
| 13:17:43 | brinzhang | I will go home now, have a holiday sean-k-mooney, gibi :D | |
| 13:17:56 | gibi | brinzhang: o/ | |
| 13:41:03 | dansmith | sean-k-mooney: compute=auto will try to select the version supported by the oldest compute service in the system, based on service_version | |
| 13:41:43 | sean-k-mooney | dansmith:yes | |
| 13:41:53 | sean-k-mooney | the max version suspport by the oldest | |
| 13:42:03 | sean-k-mooney | which is why i was saying to use 5.1 | |
| 13:42:07 | sean-k-mooney | not auto | |
| 13:42:26 | sean-k-mooney | since brinzhang is not update all the nodes | |
| 13:42:29 | dansmith | ah, you said [05:56:27] <sean-k-mooney>so i think that will default to the newest version supported by the current node | |
| 13:42:38 | dansmith | but you meant that for if it's unset or something? | |
| 13:42:48 | sean-k-mooney | yes unset | |
| 13:43:06 | dansmith | okay I was skimming the backscroll and thought you were saying that was the auto behavior, | |
| 13:43:08 | dansmith | but I see now | |
| 13:58:03 | bbowen | sean-k-mooney: Do you know the latest on https://trello.com/c/f0lLrWxf/2465-swisscom-schweiz-agsev302710209bz1860395neutronrarp-packets-after-live-migration-are-dropped-by-br-link-due-to-a-timing-issue-be, I thought you were making a change and it was not on neutron team. was a hint in rhos-prio to go back to compute | |
| 13:59:06 | bbowen | ^now on neutron | |
| 13:59:18 | lyarwood | bbowen: wrong channel :) | |
| 13:59:44 | bbowen | ty | |
| 14:34:51 | artom | stephenfin, I think I'd like a video chat to explain https://review.opendev.org/#/c/756070/6/nova/virt/hardware.py if you have some time today or next week | |
| 14:34:59 | artom | Not so much the change itself, more the context around it | |
| 14:44:24 | artom | You set `instance_cell.min_threads = threads_no`, and I'm trying to work backwards to where threads_no is coming from, and it's... hard :P | |
| 15:07:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use the non polling notification waiter in func test https://review.opendev.org/758445 | |
| 15:07:57 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Create a fixture around fake_notifier https://review.opendev.org/758446 | |
| 15:09:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use NotificationFixture for legacy notifications too https://review.opendev.org/758448 | |
| 15:10:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test the NotificationFixture https://review.opendev.org/758450 | |
| 15:10:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move fake_notifier impl under NotificationFixture https://review.opendev.org/758451 | |
| 15:13:21 | gmann | gibi: I have doctor appointment and would not be able to join today meeting. | |
| 15:13:35 | gibi | gmann: ack, thanks for the headsup | |
| 15:42:23 | lyarwood | stephenfin: you've been working on LM bugs recently with the periodic jobs right? | |
| 15:42:53 | lyarwood | stephenfin: did you find any issues with _sync_instance_power_state running *after* an instance had already paused? | |
| 15:49:46 | artom | lyarwood, I think he's on PTO this EU afernoon - he cancelled a meeting we had with Brian and Erwan | |
| 15:49:56 | lyarwood | ah forgot my bad | |
| 15:49:59 | lyarwood | thanks artom | |
| 15:51:07 | gibi | nova meeting starts in 10 minutes on #openstack-meeting-3 | |
| 16:13:48 | dansmith | melwitt: ahh, maybe the separate joins are only happening when we grab multiple instances | |
| 16:14:12 | dansmith | if that's the case, then just making the get-by-uuid path work the same would be easy | |
| 16:15:23 | melwitt | is there a specific part of the code you're looking at that makes you think that? | |
| 16:15:37 | dansmith | I shouldn't say "separate joins"... they're called "manual joins" in the db api, because they're separate queries | |
| 16:15:56 | dansmith | melwitt: look at this: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1278 | |
| 16:16:05 | dansmith | melwitt: and this: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1328 | |
| 16:16:25 | melwitt | ahh | |
| 16:17:13 | dansmith | when we moved flavor info into sysmeta, we caused a giant explosion on every instance list, right around icehouse, | |
| 16:17:41 | dansmith | so we moved to this manual join method where we query the metadata tables separately, but in bulk, to avoid the n:m join | |
| 16:18:11 | dansmith | so the single case is similar, just where n=1, but if m is large enough, still unideal | |
| 16:18:16 | sean-k-mooney | we basicaly need to use a subqurry for the userdata | |
| 16:18:29 | sean-k-mooney | and get the rest of the data normally | |
| 16:19:02 | dansmith | subquery or separate query? not sure how the former will help | |
| 16:19:23 | sean-k-mooney | seperate query | |
| 16:19:36 | dansmith | yeah, we do that on list, just don't on get, that's my point | |
| 16:19:48 | sean-k-mooney | yeah | |
| 16:20:12 | dansmith | all the machinery is there from list, so get can just call it but with the single instance we care about | |
| 16:20:18 | sean-k-mooney | i didnt look a the code specificaly but this sounded familar as i think we already optimised this once before for that list case | |
| 16:21:01 | sean-k-mooney | its just one of those things that works fine for small number and then explode because its n*m complexity | |
| 16:21:10 | sean-k-mooney | in size | |
| 16:21:11 | dansmith | for list, yeah | |
| 16:21:31 | sean-k-mooney | well in this case its joing userdata with each metadata propertiy | |
| 16:21:37 | dansmith | for single get n=1, but m is large | |
| 16:21:54 | dansmith | right | |
| 16:22:04 | sean-k-mooney | ya so its still liniar instad of O(1) | |
| 16:22:16 | sean-k-mooney | not as bad but still kind of sucks | |
| 16:22:24 | dansmith | linearly big is still big :) | |
| 16:30:32 | openstackgerrit | melanie witt proposed openstack/nova stable/ussuri: Follow up for cherry-pick check for merge patch https://review.opendev.org/758463 | |
| 16:43:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 16:45:37 | sean-k-mooney | gibi: i have seen devices that use teh 32bit domian that can be assigned to qemu | |
| 16:45:56 | sean-k-mooney | althoguh i was using a patched qemu | |