| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 08:17:37 | bauzas | efried: okay, honestly, it's prio #3 for me | |
| 08:17:45 | efried | that should work out nicely :) | |
| 08:17:48 | bauzas | but I can try to look while I wait for stephenfin and gibi | |
| 08:17:53 | openstackgerrit | Alexandra Settle proposed openstack/nova stable/stein: Fixing broken links https://review.opendev.org/681401 | |
| 08:18:54 | alex_xu | efried: bauzas I guess the only one I want to check is this https://review.opendev.org/#/c/678455/27/nova/virt/hardware.py@2065, I don't know why she can't just assign a cpu_policy and cpu_thread_plicy directly instead of using the flavor and image_metadata | |
| 08:21:10 | openstackgerrit | Brin Zhang proposed openstack/nova master: Filter migrations by user_id/project_id https://review.opendev.org/674243 | |
| 08:23:02 | luyao | efried: code ready to be reviewed, welcome :) | |
| 08:23:10 | openstackgerrit | Brin Zhang proposed openstack/nova master: Filter migrations by user_id/project_id https://review.opendev.org/674243 | |
| 08:23:46 | efried | luyao: on it now | |
| 08:25:48 | alex_xu | luyao: only thing I have https://review.opendev.org/#/c/678455/27/nova/virt/hardware.py@2072 | |
| 08:26:52 | luyao | alex_xu: Okay, I'll test it first. | |
| 08:27:13 | alex_xu | luyao: thanks a lot | |
| 08:29:25 | stephenfin | alex_xu: Nicely done :) Looking | |
| 08:29:34 | alex_xu | stephenfin: \o/ | |
| 08:30:52 | luyao | alex_xu: works well | |
| 08:31:02 | alex_xu | luyao: \o/ | |
| 08:34:00 | openstackgerrit | Merged openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565 | |
| 08:34:11 | openstackgerrit | Merged openstack/nova master: Reject live migration and suspend on SEV guests https://review.opendev.org/680158 | |
| 08:34:21 | openstackgerrit | Merged openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616 | |
| 08:34:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth https://review.opendev.org/676972 | |
| 08:35:31 | alex_xu | stephenfin: https://review.opendev.org/#/c/671800/30/nova/virt/hardware.py@2018, I'm not sure we should take crea of numa_usages_from_instance_numa in ResoourceTracker, since the RT only process the instance below to this host, if this host is upgraded, then it will host_cell.pcpuset. If this host is old, then it doesn't know about any pcpuset. But I can help you to test that | |
| 08:37:37 | gibi | bauzas: the next patch is up: https://review.opendev.org/676972 | |
| 08:37:45 | bauzas | gibi: ack, looking | |
| 08:37:49 | gibi | thanks | |
| 08:50:26 | stephenfin | alex_xu: Hmm, that's a good point actually | |
| 08:50:34 | stephenfin | I keep forgetting the resource tracker runs on the host | |
| 08:53:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth https://review.opendev.org/676980 | |
| 08:53:23 | alex_xu | stephenfin: yea, we only take care of host_cell, not the instance cell, it should be ok for any migration also | |
| 08:53:32 | aspiers | stephenfin: I just removed SEV from the runway since it merged \o/ | |
| 08:53:41 | aspiers | thanks everyone for all your help | |
| 08:54:38 | alex_xu | aspiers: congrats, destory the laptop and begin to vacation | |
| 08:54:51 | aspiers | alex_xu: exactly! X-D ;-) | |
| 08:55:02 | aspiers | I'm taking vacation next week | |
| 08:55:16 | alex_xu | aspiers: enjoy :) | |
| 08:55:22 | aspiers | thanks :) | |
| 08:55:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize https://review.opendev.org/678827 | |
| 08:55:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497 | |
| 09:00:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Allow resizing server with port resource request https://review.opendev.org/679019 | |
| 09:03:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extract pf$N literals as constants from func test https://review.opendev.org/680991 | |
| 09:04:07 | stephenfin | aspiers: \o/ | |
| 09:04:20 | stephenfin | efried: You're mad, btw | |
| 09:04:34 | stephenfin | (the getting up early thing :D) | |
| 09:05:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Improve dest service level func tests https://review.opendev.org/680998 | |
| 09:05:31 | efried | fly safe gibi | |
| 09:06:01 | efried | \o/ aspiers! | |
| 09:07:52 | alex_xu | stephenfin: sean-k-mooney efried found an intersting case for this https://review.opendev.org/#/c/681383/2 | |
| 09:08:20 | alex_xu | but I guess in the end, it will become why choice fallback to PCPU or fallback to VCPU. | |
| 09:08:37 | aspiers | efried: \o/ indeed, can't thank you enough for all your help! it's been a long road (basically a whole year IIRC) | |
| 09:08:58 | stephenfin | alex_xu: I just left comments on that | |
| 09:09:09 | stephenfin | tl;dr: I don't think we should be doing the service version check | |
| 09:09:16 | efried | aspiers: sadly, your experience was very smooth and quick compared to most of a similar size. | |
| 09:09:29 | aspiers | haha wow really :) | |
| 09:09:34 | efried | ask anyone | |
| 09:09:51 | stephenfin | aspiers: yup, he's not lying | |
| 09:09:53 | aspiers | I honestly didn't think it would be anywhere near as hard to complete, or as long | |
| 09:10:05 | aspiers | classic case of engineering underestimation | |
| 09:10:06 | stephenfin | cpu-resources is on its...fourth cycle? | |
| 09:10:06 | alex_xu | stephenfin: except we define a rule, the operator must use cpu_dedicated_set for pinning host after upgrade to T | |
| 09:10:13 | efried | it really shouldn't be, aspiers | |
| 09:10:25 | efried | ...as hard/long to complete | |
| 09:10:25 | aspiers | stephenfin: :-o | |
| 09:10:45 | stephenfin | alex_xu: I've been told we can't. We'll break upgrades. You can't require nova.conf changes simply to upgrade to a new major version | |
| 09:11:04 | aspiers | efried: what are the lessons learnt? other than we should all chip in to help fix CI more :) | |
| 09:11:36 | efried | aspiers: We keep learning the same lessons over and over again but not reacting | |
| 09:11:48 | stephenfin | aspiers: bug people and be as responsive as possible, pretty much | |
| 09:12:13 | alex_xu | stephenfin: emm...I guess because we have no way to force that, the upgrade-check can't check all the hosts' configuration file | |
| 09:12:15 | aspiers | stephenfin: pretty sure I did a lot of bugging - sorry about that ;-) | |
| 09:13:13 | stephenfin | alex_xu: Indeed. Tbh, I don't think it's an issue anyway | |
| 09:13:15 | efried | aspiers: I see the main problems being 1) we commit to too much stuff per release, and 2) we *somehow* need more consistent core engagement throughout the cycle (and it would be nice if less "bugging" was required to achieve that) | |
| 09:13:39 | stephenfin | The NUMATopologyFilter will save us | |
| 09:14:43 | alex_xu | stephenfin: what do you mean "you can't require nova.conf changes simply to ugprade to a new major version"? | |
| 09:14:59 | efried | fwiw my plan for ussuri is to be strict about 1. This was the first release where I had an employer with real business commitments based on the assumption that "approved spec" actually means a thing is expected to get done. (And that's the cycle I had to run for PTL, shoot-self-in-foot) | |
| 09:15:19 | aspiers | efried: yeah. It feels like more resources are required for reviewing in general and the cores are being pulled in too many directions at once | |
| 09:15:32 | efried | ...and therefore the first cycle I really felt the pain of stuff slipping | |
| 09:15:35 | aspiers | ouch | |
| 09:15:50 | stephenfin | alex_xu: I mean if you have Stein-based deployment that's not emitting deprecation warnings, you should be able to upgrade it to Train without changing nova.conf at all and it'll just work | |
| 09:16:08 | aspiers | I can relate - I felt a lot of pressure to land SEV in Train (original plan with AMD was Stein), although it turns out a lot of that pressure was just from me | |
| 09:16:22 | stephenfin | It might start issuing new warnings saying "you will need to do X before you upgrade to U" but that's it | |
| 09:16:27 | kashyap | aspiers: Nice on SEV completion, that's one fo the first things I was looking if it was all merged this morning. | |
| 09:16:34 | stephenfin | efried: Right? ^ | |
| 09:16:44 | aspiers | kashyap: thanks a lot for all your help! | |
| 09:17:34 | efried | stephenfin: that is my understanding, yes | |
| 09:17:40 | stephenfin | Sweet | |
| 09:17:45 | alex_xu | stephenfin: emm...right, we have rule about the configuration file should works with same as before | |
| 09:18:01 | stephenfin | alex_xu: So yeah, tl;dr: we can insist '[compute] cpu_dedicated_set' is configured before U | |
| 09:18:12 | stephenfin | and add an upgrade check to ensure that | |
| 09:18:17 | stephenfin | but not T | |
| 09:18:19 | kashyap | aspiers: NP; glad to be useful. Now I can bug you for Secure Boot stuff -- turning out to be more work than I anticipated :/ | |
| 09:18:27 | stephenfin | because we gave them no warning and no migration path in Stein | |
| 09:18:50 | stephenfin | alex_xu: However, yeah, I don't think this is in an issue. Consider this | |
| 09:19:58 | aspiers | kashyap: bug soon as I'm on vacation next week ;-) | |
| 09:20:01 | stephenfin | Stein-based compute node: reports VCPU, uses NUMATopology.cpuset to determine what cores can be pinned to (with the NUMATopologyFilter simply copying 'cpuset' to 'pcpuset' to keep that passing) | |
| 09:20:16 | kashyap | aspiers: Heh, noted; well-deserved | |
| 09:21:19 | stephenfin | Train-based compute node without new config options: reports VCPU, uses NUMATopology.pcpuset (p!) to determine cores can be pinned to but this == NUMATopology.cpuset (so no need for NUMATopologyFilter to copy 'cpuset' to 'pcpuset') | |
| 09:21:49 | alex_xu | yup | |
| 09:22:04 | stephenfin | Train-base compute node with new config options: reports PCPU, uses NUMATopology.pcpuset (p!) to determine cores can be pinned to and this is unique (again, no need for NUMATopologyFilter to copy 'cpuset' to 'pcpuset') | |
| 09:22:05 | stephenfin | sooo | |
| 09:22:23 | stephenfin | from a placement perspective, things have changed | |
| 09:23:00 | luyao | efried: do you need a unittest for this? https://review.opendev.org/#/c/678450/11/nova/compute/manager.py@2224 | |
| 09:23:10 | stephenfin | but from a NUMATopologyFilter (nova-scheduler) and nova-compute perspective, all three will work perfectly fine together | |