| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 15:41:29 | kashyap | aspiers: Go for it; more important. Damn screens can cait. | |
| 15:41:31 | kashyap | s/cait/wait/ | |
| 15:41:35 | aspiers | ;-) | |
| 15:41:48 | efried | mdbooth, lyarwood: Thoughts on how long https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder should take? | |
| 15:41:52 | efried | be conservative, please. | |
| 15:42:58 | cfriesen | So as I mentioned to Kashyap, I think we've got an issue with UEFI boot on recent CentOS/RHEL. https://bugs.launchpad.net/nova/+bug/1825386 | |
| 15:42:59 | openstack | Launchpad bug 1825386 in OpenStack Compute (nova) "nova is looking for OVMF file no longer provided by latest CentOS" [Undecided,New] | |
| 15:43:04 | smcginnis | I think in the past we've always done half a day, but there's not as many in-flight nova-cinder things at the moment. | |
| 15:43:27 | kashyap | cfriesen: An ugly workaround is to symlink the file name | |
| 15:43:56 | cfriesen | kashyap: all sorts of possible workarounds, but I'm assuming we want nova to work out of the box. | |
| 15:44:31 | mdbooth | efried: Depends. If it branches into a separate discussion of 'internal apis' it could take a long time. | |
| 15:44:36 | efried | smcginnis: Half a day? I've remembered an hour or two over the past three PTGs or so, never half a day. In any case, a) there's one small-looking topic on that list, and b) very compressed time. | |
| 15:44:55 | efried | mdbooth: See b) above. We've got to time box it. | |
| 15:45:01 | efried | given that, what do you think, an hour? | |
| 15:45:16 | mdbooth | efried: Purely api definition and discussion, 30-60 mins. | |
| 15:45:39 | efried | okay, thanks. | |
| 15:45:45 | aspiers | Yikes, SEV is the second largest nova spec to date | |
| 15:46:07 | efried | aspiers: what's the largest? | |
| 15:46:17 | aspiers | specs/newton/implemented/generic-resource-pools.rst | |
| 15:46:28 | efried | phew. I thought it was going to be one of mine | |
| 15:46:32 | aspiers | XD | |
| 15:46:41 | elod | mriedem: meanwhile i've generated the unreleased Changes between 16.1.7 and 9191083, so i can paste it to etherpad if you need | |
| 15:46:42 | efried | maybe would have been if dansmith hadn't red-penned it | |
| 15:47:08 | aspiers | Well surely SEV has to be up there in the red-pen stakes X-D | |
| 15:48:21 | smcginnis | efried: Maybe it just felt like half a day. :) | |
| 15:48:23 | kashyap | cfriesen: Oh, yes! | |
| 15:48:37 | kashyap | cfriesen: Please read the spec. All that hard-coding in Nova is fugly, and will go | |
| 15:49:18 | cfriesen | kashyap: reading it now. I think we should fix (or at least bandaid) nova in the meantime. | |
| 15:50:00 | cfriesen | kashyap: so is /usr/share/OVMF/OVMF_CODE.secboot.fd a superset of /usr/share/OVMF/OVMF_CODE.fd ? I haven't gone digging yet. | |
| 15:51:27 | kashyap | cfriesen: I would not the word "superset", but they are two distinct things | |
| 15:51:42 | kashyap | cfriesen: The binary: /usr/share/OVMF/OVMF_CODE.secboot.fd -- has Secure Boot + SMM built into it | |
| 15:52:10 | kashyap | cfriesen: While the "plain" /usr/share/OVMF/OVMF_CODE.secboot.fd -- does *not* have Secure Boot ability baked into it at buld time | |
| 15:52:58 | kashyap | cfriesen: Can add a band-aid to look for this file, too. In addition to what Nova already looks | |
| 15:54:22 | cfriesen | kashyap: I think we've also got to deal with https://bugs.launchpad.net/nova/+bug/1633447 and https://bugs.launchpad.net/nova/+bug/1785123 before secure boot is really useful, right? | |
| 15:54:24 | openstack | Launchpad bug 1633447 in OpenStack Compute (nova) "nova stop/start or reboot --hard resets uefi nvram" [Undecided,In progress] - Assigned to Jack Ding (jackding) | |
| 15:54:25 | openstack | Launchpad bug 1785123 in OpenStack Compute (nova) "UEFI NVRAM lost on cold migration or resize" [Low,In progress] - Assigned to Jack Ding (jackding) | |
| 15:55:58 | kashyap | cfriesen: I've had a cursory look, but needs more concentration; for tomm / Tuesday (Mon is a holiday). | |
| 15:57:14 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653511 | |
| 15:57:39 | cfriesen | I'm off most of next week, so don't expect quick response if you leave review comments. (I'm mostly taking over for jackding.) | |
| 15:58:37 | kashyap | (Nod) | |
| 16:04:04 | openstackgerrit | melanie witt proposed openstack/nova stable/queens: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653512 | |
| 16:04:25 | mriedem | efried: https://etherpad.openstack.org/p/nova-stable-pike-em is up to date | |
| 16:05:11 | efried | thanks mriedem | |
| 16:05:50 | mriedem | tl;dr novaclient is ready for final release, no open changes, | |
| 16:05:57 | mriedem | os-vif has no open changes nor any changes since the last release, so it's ready for em | |
| 16:06:06 | mriedem | nova has 6 pending | |
| 16:09:36 | efried | tonyb[m]: ^ FYI | |
| 16:09:46 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653514 | |
| 16:10:25 | lyarwood | efried / mdbooth ; sorry was stuck on a call, I'd say 30mins to be conservative | |
| 16:10:57 | efried | lyarwood: Cool, we've set it up for 1115-1150 | |
| 16:11:28 | efried | if really needed we can come back after team picture and go til lunch | |
| 16:13:51 | lyarwood | efried: ack thanks | |
| 16:16:44 | cfriesen | kashyap: what happens if you have running instances using /usr/share/OVMF/OVMF_CODE.fd, then you shut down the node, upgrade the OVMF RPM, and boot the node. Are the instances all toast? | |
| 16:17:54 | kashyap | cfriesen: Have not tested it; but I'd expect some error. I don't think instance will be "toast". Because it's "only" the firmware. | |
| 16:18:15 | cfriesen | but we wouldn't be able to boot it, as the xml would be specifying the "wrong" file | |
| 16:18:18 | kashyap | cfriesen: Can you try on one instance, by doing the fugly workaround of: | |
| 16:18:22 | kashyap | ln -sf /usr/share/OVMF/OVMF_CODE.secboot.fd /usr/share/OVMF/OVMF_CODE.fd | |
| 16:18:37 | kashyap | Does it boot, if you do the above? | |
| 16:18:55 | cfriesen | I don't have a suitable setup at the moment. | |
| 16:20:06 | kashyap | cfriesen: But yes -- obviously, instance won't boot if the file is missing | |
| 16:20:34 | cfriesen | I'm wondering why RHEL/Centos didn't include both OVMF_CODE.fd and OVMF_CODE.secboot.fd in the RPM | |
| 16:20:58 | gmann | mriedem: fixed all formatting and scheduler_hints - https://review.openstack.org/#/c/603969/ | |
| 16:22:02 | cfriesen | kashyap: oooh, interesting. the fedora package has both | |
| 16:22:11 | kashyap | cfriesen: Yes | |
| 16:22:26 | kashyap | cfriesen: This whole OVMF binary file names across distributions is a cluster fuck sized Jupiter | |
| 16:22:31 | kashyap | cfriesen: But ... good news! | |
| 16:22:56 | kashyap | cfriesen: That's why upstream QEMU we introduced a formal *schema* (the @Firmware thing you read) | |
| 16:23:30 | kashyap | cfriesen: Because the firmware paths and names differ _across_ distros. E.g. see this on Ubuntu: https://packages.ubuntu.com/disco/all/ovmf/filelist | |
| 16:27:29 | kashyap | cfriesen: Anyway, all of this is resolved now (and much more simpler) thanks to a lot of work in EDK2/OVMF, QEMU & libvirt. | |
| 16:27:54 | kashyap | More details in a firefox tab (with the Secure Boot spec) near you :D | |
| 16:28:03 | cfriesen | yeah, it'll be better in another release cycle. | |
| 16:28:09 | cfriesen | later | |
| 16:28:31 | mriedem | gmann: comments inline :) but it's pretty good. | |
| 16:29:05 | mriedem | gmann: i'll probably just +1 once you fix those since we're close to the ptg and i want to make sure other cores (and ops/users) are aware of what's being proposed here before we move forward | |
| 16:29:19 | gmann | mriedem: sure, i will update | |
| 16:29:25 | mriedem | i think the majority of the team needs to approve or at least be aware and not care since this is a pretty big change | |
| 16:29:48 | gmann | make sense. | |
| 16:35:38 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Drop legacy-grenade-dsvm-neutron-multinode-live-migration from Pike https://review.openstack.org/653811 | |
| 16:35:45 | mriedem | dansmith: melwitt: ^ spring cleaning | |
| 16:38:14 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 16:38:30 | gmann | mriedem: ^^ done | |
| 16:41:48 | melwitt | mriedem: curious how the job is broken if it's passing? | |
| 16:42:13 | mriedem | it's not | |
| 16:42:15 | mriedem | non-voting | |
| 16:42:31 | mriedem | see https://review.openstack.org/#/c/640207/ | |
| 16:42:58 | mriedem | if you really want to go mad, you can read my ramblings in https://review.openstack.org/#/c/640197/ trying to fix the job in queens | |
| 16:43:13 | melwitt | oh, ok. I was confused by "removes the (broken) non-voting job" | |
| 16:44:02 | mriedem | tl;dr one of the nodes is using nova-cpu.conf and one is using nova.conf and as a result, only one of them has the rbd creds which means the ceph stuff all fails during live migration | |
| 16:44:22 | mriedem | i guess one way for me to deal with the busted job on queens is to just nix the rbd testing so we still have just block migration live migration | |
| 16:44:34 | melwitt | ah ok | |
| 16:57:30 | aspiers | sean-k-mooney: latest patch set of SEV spec is fully converted to the resource class approach https://review.openstack.org/#/c/641994/9 | |
| 16:57:49 | aspiers | cdent / jaypipes might be interested too | |
| 17:01:31 | cdent | thanks aspiers, putting it on the list | |
| 17:01:39 | aspiers | cheers | |
| 17:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640197 | |
| 17:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640198 | |
| 17:04:05 | sean-k-mooney | aspiers: loook like there is a pep8 issue jsut an fyi | |
| 17:04:10 | aspiers | darn | |
| 17:05:05 | aspiers | weird, can't see that locally | |
| 17:05:22 | aspiers | oh, wrong environment | |