| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 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 | |
| 17:05:37 | aspiers | I wonder why tox -e flake8 is allowed | |
| 17:07:18 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | |
| 17:07:22 | aspiers | sean-k-mooney: fixed | |
| 17:32:30 | cdent | aspiers: that's the just the unfortunate way tox works... | |
| 17:32:38 | openstackgerrit | Merged openstack/nova master: libvirt: set device address tag only if setting disk unit https://review.openstack.org/611974 | |
| 17:59:26 | efried | aspiers: Re-reviewed SEV spec | |
| 17:59:57 | aspiers | efried: thanks | |
| 17:59:58 | efried | cdent: I tried to explain there ^ why we don't ever remove things from os-traits, even if they're trash. | |
| 18:00:14 | efried | perhaps you can reinforce/augment | |
| 18:00:25 | cdent | efried: looking | |
| 18:05:12 | aspiers | efried, cdent: To "The pathological theoretical case is where somebody (not limited to nova) is on 0.11.0 or 0.12.0, sees the trait and uses it for $whatever", my question is: what could $whatever possibly be? Literally there is zero code which uses it. | |
| 18:06:05 | efried | I'm basically saying it doesn't matter | |
| 18:06:06 | aspiers | And even if they somehow concocted some way to use it, that couldn't possibly relate to SEV in any way, because again there is zero SEV code merged which uses it anywhere. | |
| 18:06:32 | cdent | aspiers, efried : the additional aspect is that whenever a placement service sees a new version of os-traits it syncs up its database with the strings that are in the package, creating a row in the traits table, with an id that becomes a foreign key in other tables | |
| 18:06:40 | cdent | s/becomes/can become/ | |
| 18:06:44 | aspiers | Ahah | |
| 18:06:52 | aspiers | Now that sounds like it could be a good reason | |
| 18:06:55 | cdent | nothing is present is in placement to do a reverse sync | |
| 18:07:02 | aspiers | Gotcha | |
| 18:07:25 | aspiers | In any case, it's trivial to ditch the removal from the spec, and I'm happy to do that | |
| 18:07:40 | aspiers | I just wanted to understand the rationale out of curiosity ;-) | |
| 18:07:40 | cdent | that wasn't the reason why we can't remove, but once we decided we -weren't- going to remove, then it became safe for the sync mechanism to be that | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | |