Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-18
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: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640198
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: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 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:40 aspiers I just wanted to understand the rationale out of curiosity ;-)
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
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:53 aspiers Yep that makes sense
18:07:53 openstackgerrit melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324
18:08:18 cdent but the general ideas was simply: an extensible only enumeration is easier to manage than one than can be shrunk
18:08:32 aspiers Sure

Earlier   Later