Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-18
14:32:09 kashyap mriedem: I was _just_ about to say that; to split out that giant CI JSON bits away from the main Etherpa
14:49:02 kashyap cfriesen: Heya, mind having a gander at this Secure Boot spec: https://review.openstack.org/#/c/506720
14:49:58 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add missing libvirt exception during device detach https://review.openstack.org/651642
14:50:36 kashyap mriedem: Heh, I was referring to this (Hyper-V) commit of yours & Claudiu: http://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=29dab997
14:51:38 kashyap The stuff I'm adding in the spec is similar, but for the open source hypervisor
14:52:09 mriedem kashyap: don't confuse me as the author there, that was probably due to a bad rebase which changed the author
14:52:16 mriedem i was likely just helping to clean up nits to get it approved
14:52:33 kashyap Yeah, I know Claudiu was driving it
14:54:21 mriedem cdent: if you have hooks to rado, can you ask if we really need this in pike? https://review.openstack.org/#/c/613263/
14:54:40 cdent i can probalby find him, yeah
14:55:34 sean-k-mooney mriedem: by the way for NewBruce RDO -> OSA bug. they tested my backported fix last night and it worked at least for the test instnace.
14:56:01 mriedem sean-k-mooney: i need to read your commit message to figure out what the problem was
14:56:16 mriedem or we don't know what the problem was, but this works around it
14:56:33 mriedem i'm also doing about 10 other things atm
14:56:58 sean-k-mooney so we know what the problem is and this works fixes it but i still dont know what teh cause is. im going to try and figure out a reporducer
14:57:31 elod mriedem: only that have stable-policy-follows tag
14:57:37 cdent mriedem: i've pinged him, but based on a cursory examination I think your analysis is correct. If we don't hear anything from him, probably safe to kill/ignore
14:57:50 sean-k-mooney mriedem: no worries i just wanted to say im going to be away for a few days due to pulic holidays but ill try to get back to working on it before the ptg
14:58:04 mriedem cdent: cool thanks
14:58:19 elod mriedem: did i miss something?
14:58:24 mriedem i'm glad you dropped the b rather than l in 'public'
14:58:41 mriedem elod: no i'm just trying to organize the nova pike-em work
14:58:46 mriedem using https://etherpad.openstack.org/p/nova-stable-pike-em
14:59:04 sean-k-mooney :) yes so am i
15:00:22 elod mriedem: ok, is see. actually the pads are quite out-of-date, maybe i should update them
15:00:43 gibi mriedem: replied in https://review.openstack.org/#/c/652608/ but I have to disappear now
15:00:51 elod mriedem: i see that you updated nova's etherpad already
15:04:44 mriedem elod: yeah i'm working on onva's
15:04:46 mriedem *nova's
15:08:07 mriedem cdent: i left some more details about why maybe that patch would still be good for vcenter but i'm not sure - maybe only in the 1:M host:node case but i thought we stopped doing that with vcenter back in like kilo or liberty - long before you had to care about it :)
15:08:20 mriedem tl;dr i think we can drop it
15:14:02 cdent mriedem: in addition to all that, from a vio/vmware standpoint, pike doesn't really matter any more
15:15:10 mriedem heh that was my other guess
15:25:14 cfriesen kashyap: it looks like centos 7.6 has modified the OVMF-20180508-3 rpm to no longer contain the file /usr/share/OVMF/OVMF_CODE.fd that nova looks for in nova/virt/libvirt/driver.py. Instead it now seems to be named /usr/share/OVMF/OVMF_CODE.secboot.fd
15:25:39 kashyap cfriesen: I think it is following just RHEL.
15:25:48 kashyap cfriesen: It's a good step: because it keeps things simpler
15:25:51 cfriesen likely...but either way nova has an issue
15:26:03 kashyap cfriesen: Because we hardcode the file
15:26:04 kashyap I know
15:26:34 cfriesen is anyone planning on making it a config option or something?
15:26:34 kashyap That will go away. We will use the convenient formal interfaces provided by libvirt and QEMU
15:26:37 cfriesen ah
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.

Earlier   Later