| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 12:43:05 | sean-k-mooney | well im planning to use it there | |
| 12:43:26 | sean-k-mooney | and if we used xpath in config.py more liberally it would be much shorter then it currently is | |
| 12:43:38 | aspiers | maybe | |
| 12:43:52 | aspiers | sean-k-mooney: feel free to add me to the review | |
| 12:43:57 | sean-k-mooney | https://review.opendev.org/#/c/666915/6/nova/virt/libvirt/config.py@182 | |
| 12:44:12 | kashyap | aspiers: On your pastebin (http://paste.openstack.org/show/755058/): you lack the 'efi' bit because, (a) old version; (b) your EDK2/OVMF package doesn't yet have these files: | |
| 12:44:16 | kashyap | /usr/share/qemu/firmware | |
| 12:44:18 | kashyap | /usr/share/qemu/firmware/40-edk2-ovmf-x64-sb-enrolled.json | |
| 12:44:21 | kashyap | /usr/share/qemu/firmware/50-edk2-ovmf-x64-sb.json | |
| 12:44:23 | kashyap | /usr/share/qemu/firmware/60-edk2-ovmf-x64.json | |
| 12:44:26 | kashyap | --- | |
| 12:45:29 | aspiers | kashyap: /usr/share/qemu/firmware doesn't exist at all | |
| 12:45:56 | sean-k-mooney | i dont see that on ubunut | |
| 12:46:13 | kashyap | aspiers: Right - it doesn't exist on those yet. Hence these RFEs I filed for Debian and Ubuntu: | |
| 12:46:25 | kashyap | aspiers: It is part of QEMU 4.1 (coming next month) - merged in Git. | |
| 12:46:29 | kashyap | The files. | |
| 12:46:54 | aspiers | ouch, 2.11.2 here | |
| 12:46:58 | kashyap | (But each distro should ship a variant of those files that matches with their EDK2/OVMF.) | |
| 12:47:02 | sean-k-mooney | i have it in a different location on debian | |
| 12:47:19 | kashyap | sean-k-mooney: The JSON files don't exist yet on Debian | |
| 12:47:20 | sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fs | |
| 12:47:23 | sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fd | |
| 12:47:36 | aspiers | sean-k-mooney: that's not the json files | |
| 12:47:42 | aspiers | that's the blobs | |
| 12:47:43 | kashyap | sean-k-mooney: We're talking about .json files | |
| 12:47:43 | sean-k-mooney | oh the json file is seperate form the firmware image | |
| 12:48:03 | kashyap | Here are the RFEs I filed for Debian/Ubuntu: | |
| 12:48:11 | kashyap | (1) Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 | |
| 12:48:11 | openstack | Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Open] | |
| 12:48:12 | sean-k-mooney | no its fine | |
| 12:48:18 | kashyap | (2) Ubuntu: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1836859 | |
| 12:48:18 | openstack | Launchpad bug 1836859 in edk2 (Ubuntu) "RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package" [Undecided,New] | |
| 12:49:10 | kashyap | coreycb: Hi, any update on the above from 'dannf'? --^ | |
| 12:49:32 | kashyap | coreycb: Sorr for pestering; I'll be off from 06-Aug to 23-Aug, trying to get it into Ubuntu by then | |
| 12:49:53 | kashyap | coreycb: It's a simple change, just requires one to go through the motions and get a package build out. | |
| 12:49:57 | sean-k-mooney | they may still decide to package tehm in a different location but you know more about it then i | |
| 12:50:33 | kashyap | sean-k-mooney: They can package it in whatever location - it doesn't matter, so long as they're shipping the JSON file with their custom path. | |
| 12:50:37 | sean-k-mooney | i think its somewhat confusing that they are in the qemu directory and not in OVMF | |
| 12:51:09 | kashyap | sean-k-mooney: That is what the QEMU firmware specifcation looks for. | |
| 12:51:17 | kashyap | https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json#l312 | |
| 12:51:31 | kashyap | 312 # - /usr/share/qemu/firmware -- populated by distro-provided firmware | |
| 12:51:34 | kashyap | 313 # packages (XDG_DATA_DIRS covers | |
| 12:51:37 | kashyap | 314 # /usr/share by default), | |
| 12:51:44 | sean-k-mooney | i guess it depends on if its in the qemu package or ovmf package | |
| 12:51:53 | sean-k-mooney | its edk2 | |
| 12:52:20 | kashyap | For distributions shipping EDK2/OVMF, they should ship these files as part of that package. | |
| 12:53:19 | sean-k-mooney | right so it seam weird that that package would add somthing to the qemu firmware folder unless that package has a hard depency on qemu e.g. it cant be instlled without it | |
| 12:54:06 | aspiers | kashyap: weirdly, changing the commit message only invalidated the V+1 of that commit, not all the others rebased above it | |
| 12:54:20 | sean-k-mooney | yep | |
| 12:54:40 | sean-k-mooney | if gerrit can tell that the rest of the content did not change it wont drop the +/- 1 | |
| 12:55:03 | sean-k-mooney | so if you are just fixing a commit message then it will generally keep everything else as long as you did not rebase | |
| 12:55:59 | kashyap | sean-k-mooney: The /usr/share/qemu is not weird -- why? Because QEMU (4.1 onwards) _itself_ ships bundled EDK2 + JSON firmware files | |
| 12:56:34 | kashyap | But those distributions building QEMU (and EDK2/OVMF) decouple that and ship separately | |
| 12:56:46 | kashyap | aspiers: I'm writing a "summer time update" to the SUSE folks; look out for an e-mail | |
| 12:57:00 | aspiers | kashyap: great | |
| 12:57:31 | sean-k-mooney | the relationship is inverted if edk2 does not depend on qemu it shouldnt modify qemu directories but anyway i dont really want to dicuss this now | |
| 12:58:09 | sean-k-mooney | if the json files were part of the qemu package the current state makes sense to me | |
| 12:58:21 | coreycb | kashyap: i think he's on pto | |
| 12:58:35 | efried | sean-k-mooney: what's the question? Whether service tokens are still experimental? | |
| 12:58:53 | sean-k-mooney | efried: the question is can we enable them by default | |
| 12:58:53 | coreycb | kashyap: this is for qemu 4.1 right? | |
| 12:59:02 | efried | aspiers: Re Element.getchildren() -- sure; I'm assuming there's a fairly straightforward replacement. | |
| 12:59:05 | sean-k-mooney | efried: or rather should we | |
| 12:59:17 | aspiers | efried: literally just dropping ".getchildren()" | |
| 12:59:25 | aspiers | efried: for child in parent: | |
| 12:59:37 | aspiers | or children = list(parent) | |
| 13:00:08 | sean-k-mooney | efried: they implemented the iterator protocol on the Element class so you can now just use list() itter() or pass it to a for loop and it will loop over the childeren | |
| 13:00:45 | kashyap | coreycb: Yes, it is for QEMU 4.1 (coming out in the 2nd week of August). But no need to wait for the release | |
| 13:01:17 | kashyap | aspiers: A quick one: what is the package called on SUSE? 'edk2' or 'edk2-ovmf' or 'ovmf'? | |
| 13:01:19 | efried | aspiers: neat. Then yeah, for sure, let's get a patch up. | |
| 13:01:43 | coreycb | kashyap: right so from what i understand 19.10 won't have qemu 4.1 so we have time. it's slated for 20.04. | |
| 13:03:32 | efried | sean-k-mooney: When you say enable by default, the operator would still have to put admin creds into the service_user section of the conf to make it work; you're just suggesting getting rid of the need for the extra [service_user]send_service_user_token granny switch? | |
| 13:04:09 | aspiers | kashyap: not sure but you can probably find out from these ... https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP4:Update/ovmf/ovmf.spec?expand=1 | |
| 13:04:16 | aspiers | https://build.opensuse.org/package/view_file/SUSE:SLE-15:Update/ovmf/ovmf.spec?expand=1 | |
| 13:04:23 | kashyap | coreycb: When is 20.04 out? | |
| 13:04:36 | kashyap | coreycb: Note: this _doesn't_ require QEMU 4.1 per-se | |
| 13:04:48 | aspiers | https://build.opensuse.org/package/show/hardware:boot/edk2 | |
| 13:05:09 | coreycb | kashyap: april of 2020. right but i imagine that's how it will be prioritized. | |
| 13:05:23 | sean-k-mooney | efried: i may not fully understand this feature but i was fering to removing of chaning the defualt of https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L28-L43 | |
| 13:05:33 | kashyap | aspiers: Actually, I found it documented in my own spec :-) -- the pacakge in SLES is called: qemu-ovmf-x86_64 | |
| 13:05:41 | aspiers | efried, kashyap: so SEV needs UEFI and currently the only way to activate this is hw_firmware_type=uefi on the image. What if an image without this is booted with hw:mem_encryption='True' ? | |
| 13:06:06 | aspiers | Should nova throw an error, or impose uefi on the image? | |
| 13:06:15 | sean-k-mooney | i guess you also need to set up the service user | |
| 13:06:17 | aspiers | sean-k-mooney: interested in your opinion too | |
| 13:06:29 | kashyap | coreycb: Well, why can't the package be even available in the "latest" Git distro? (In Fedora's terms, "Rawhide") | |
| 13:06:44 | kashyap | coreycb: Fedora already ships these for a couple of weeks. There's no reason to delay this | |
| 13:06:56 | sean-k-mooney | aspiers: does sev only work with uefi guests | |
| 13:07:02 | aspiers | yes | |
| 13:07:09 | coreycb | kashyap: i'm not the maintainer i'm just assuming how it will work | |
| 13:07:29 | aspiers | it's mentioned in the spec | |
| 13:07:32 | kashyap | aspiers: Hmm, I'd say "impose UEFI on the image" -- if it's a prereq for SEV -- but ... I don't off-hand if any caveats need to be thought out | |
| 13:07:32 | sean-k-mooney | then you should have a check in the api and reject the spawn before we create a request spec or instance object | |
| 13:07:33 | aspiers | albeit briefly | |
| 13:08:02 | aspiers | kashyap: I'm more inclined to agree with sean-k-mooney's suggestion here | |
| 13:08:08 | aspiers | let's see what efried thinks | |
| 13:08:09 | kashyap | coreycb: Noted. I'd also assume any other Debian packager submitting the change / patch shold be accepted. I hope the process is not blocked on a single maintainer. | |
| 13:08:35 | sean-k-mooney | you can do it like this https://review.opendev.org/#/c/671338/4/nova/compute/api.py | |
| 13:08:47 | efried | aspiers: I don't know what any of that means, but it sounds like you've got a couple of choices: | |
| 13:08:47 | efried | 1) make hw_firmware_type=uefi automatic when hw:mem_encryption=True (or... vice versa?) | |
| 13:08:47 | efried | 2) make the operation fail if hw:mem_encryption=True but hw_firmware_type!=uefi | |