Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-18
15:26:44 kashyap cfriesen: They've _vastly_ simplified it.
15:27:07 kashyap It took more than one year (necessarily so) to get all the work done across EDK2/OVMF, QEMU, libvirt merged
15:27:36 kashyap cfriesen: Since I've see you on #qemu, OFTC. I know you're comfortable with looking at some QEMU docs, let me point you to somethin
15:28:28 cfriesen kashyap: you started this in 2017? yikes. :)
15:28:32 kashyap cfriesen: The firmware.json file, and specifically read the "@Firmware:" bit: https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json#l297
15:28:53 kashyap cfriesen: Yes! I've posted periodic updates. :-) Because work needs to be done in QEMU
15:29:24 kashyap cfriesen: The main work started with this RFC I posted to 'qemu-devel':
15:29:29 kashyap https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html
15:29:39 kashyap "[RFC] Defining firmware (OVMF, et al) metadata format & file"
15:29:41 cfriesen for some reason it's taking forever to open that link
15:30:07 kashyap cfriesen: Which one? The git.qemu.org? Strange. Since you have the repo locally, look at it
15:30:09 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994
15:30:36 kashyap cfriesen: See the "Work Items" section in the spec. I've spent a lot of time tring to be as clear as I can
15:31:45 kashyap cfriesen: Note, I had to pause the spec for a year, because the main libvirt bits (firmware auto-selection) merged in 5.2, which released earlier this week :-)
15:33:47 mriedem melwitt: your rocky/queens/pike backports for https://review.openstack.org/#/q/Iefab05e84ccc0bf8f15bdbbf515a290d282dbc5d are all failing unit tests for a real issue
15:33:50 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994
15:34:53 melwitt mriedem: yeah, I saw zuul -1s and concerned it's real but I haven't dug in yet
15:34:59 cfriesen kashyap: just read the @Firmware section. that looks useful. do any distros support it yet?
15:35:31 kashyap cfriesen: Very good question.
15:35:56 kashyap cfriesen: The firmware.json file is supported by current QEMU versions. But, they went one step ahead, and also provided the firmware descriptor files
15:36:06 mriedem bauzas: dansmith: can you hit these backports? https://review.openstack.org/#/q/topic:bug/1819963+(status:open+OR+status:merged)+branch:stable/queens
15:36:11 kashyap cfriesen: That thing will be in QEMU 4.1 (July/August). Should be ready for Train
15:36:31 aspiers efried: latest patch set of SEV spec is fully converted to the resource class approach https://review.openstack.org/#/c/641994/9
15:36:32 bauzas mriedem: on a meeting (again) but sure, will look
15:36:33 mriedem lyarwood: melwitt: want to hit this backport? https://review.openstack.org/#/c/647630/
15:36:57 openstackgerrit Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645520
15:37:00 efried aspiers: Cool. Did you get feedback from other stakeholders on that approach before you did that?
15:37:09 kashyap cfriesen: Look at this one, which has the documentation: https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg01558.html
15:37:12 melwitt mriedem: queued
15:37:14 efried aspiers: (once again, I'm not caught up)
15:37:38 kashyap cfriesen: Those files will be part of QEMU 4.1, which will be shipped by distros Real Soon Now.
15:37:57 aspiers efried: Not yet, but I can't actually imagine how else we could solve the guest limit problem, so any other version of the spec proposal would be incomplete or dishonest right now
15:38:08 aspiers efried: and there's always git if I need to revert bits ;-)
15:38:14 dansmith mriedem: yeah
15:38:19 efried aspiers: fair enough.
15:38:24 mriedem dansmith: thanks
15:38:55 aspiers kashyap: finally reading your comments
15:39:24 mriedem need a stable core on https://review.openstack.org/#/c/647913/ as well
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

Earlier   Later