Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-18
15:39:53 mriedem smcginnis: tonyb[m]: ^?
15:40:13 smcginnis Looking
15:41:01 aspiers kashyap: sounds reasonable, I'll take a stab at splitting up shortly
15:41:19 aspiers going out for a run in the sun first though :)
15:41:22 kashyap aspiers: Ah, good. I was briefly worrying if I missed to consider anything else
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

Earlier   Later