| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 10:37:26 | sean-k-mooney | having said that for openstack | |
| 10:37:42 | sean-k-mooney | you would be useing datacenter volume licences | |
| 10:37:42 | kashyap | That sounds incredibly messy | |
| 10:37:53 | kashyap | Regardless, I think it robust to _assume_ it changes | |
| 10:39:30 | sean-k-mooney | well it makes sense. they assume if you buy windows your self. e.g. a retail copy that you might be building your own pc and might upgrade it | |
| 10:39:56 | sean-k-mooney | but if you go windows with your pc e.g. form dell its an oem license | |
| 10:40:01 | aspiers | kashyap: what I see from my SEV machine is lacking some of the bits you see: http://paste.openstack.org/show/755058/ | |
| 10:40:17 | aspiers | kashyap: is my libvirt or qemu old or something? | |
| 10:40:55 | sean-k-mooney | and they assume since you baugt prebuilt your not going to swap out the motherboard, you can buy oem license and they are cheaper but its one of the limitations that come with the cost reduction | |
| 10:41:51 | sean-k-mooney | but in either case its against the windows desktop license agreement to use either for systems that are purly virtualised | |
| 10:43:03 | sean-k-mooney | to run windows permently in a vm you need a different licnese (volume licenseing or datacenter) which have different activation critia | |
| 11:28:48 | sean-k-mooney | the nova-next job is ment to test thing that we intend to make the default in a subsequent release right | |
| 11:29:17 | sean-k-mooney | or is it for something else? | |
| 11:31:03 | sean-k-mooney | it looks like it was orignially for placmenet and cells testing when they were optional and for stien was the first full python 3 job? so it evelovs to test the futrue state we expect nova to run in | |
| 11:33:04 | sean-k-mooney | the reason im asking it related to a donwstream converstation about service tokens | |
| 11:33:09 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L18-L42 | |
| 11:33:28 | sean-k-mooney | it look like we have not considerd service tokens to be experimental since 2017 | |
| 11:33:50 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion 2.75: Add 'power-update' external event https://review.opendev.org/645611 | |
| 11:33:54 | sean-k-mooney | and nova-next has been running with them for over 2 years | |
| 11:34:33 | sean-k-mooney | lyarwood has a patch https://review.opendev.org/#/c/673226/1 to enable them by defualt in devstack but im wondering should we just enable it by default in nova | |
| 11:34:57 | sean-k-mooney | efried: johnthetubaguy bauzas ^ any input on that? | |
| 11:46:31 | openstackgerrit | Huachang Wang proposed openstack/nova master: doc: correct the information of 'cpu_map' https://review.opendev.org/673272 | |
| 12:09:09 | aspiers | kashyap: let me know when you're back | |
| 12:09:25 | aspiers | kashyap: I'm changing the patch title to "Track libvirt host/domain capabilities for multiple machine types" | |
| 12:27:46 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Multiple API cleanup changes https://review.opendev.org/666889 | |
| 12:30:39 | aspiers | kashyap, efried: I noticed that Element.getchildren() is deprecated since lxml 2.7 and our requirements has >= 3.4.1 - would it make sense to submit a patch getting rid of those? | |
| 12:34:58 | sean-k-mooney | aspiers: you are ment to just do list(element) now right to get the childeren | |
| 12:35:06 | aspiers | sean-k-mooney: yes I know | |
| 12:35:13 | aspiers | sean-k-mooney: my new code is already doing that | |
| 12:35:17 | sean-k-mooney | i guess iter(element) should work as well | |
| 12:35:30 | aspiers | just "for child in parent:" works fine | |
| 12:35:40 | sean-k-mooney | ah yes | |
| 12:35:51 | sean-k-mooney | personally i prefer using xpath expressions | |
| 12:35:59 | aspiers | that's a different use case | |
| 12:37:17 | sean-k-mooney | proably but it really depends on what your doing int he body of that for | |
| 12:37:48 | kashyap | aspiers: Sorry, wasn't paying close attention | |
| 12:38:25 | kashyap | aspiers: On that patch from Dirk, it's not only SLES, even CentOS is affected -- https://bugs.launchpad.net/nova/+bug/1825386 | |
| 12:38:25 | openstack | Launchpad bug 1825386 in OpenStack Compute (nova) "Nova is looking for OVMF file no longer provided by CentOS 7.6" [Undecided,New] | |
| 12:38:41 | kashyap | aspiers: (And yes, the new patch title is far more accurate; thank you) | |
| 12:39:15 | aspiers | let's see how Gerrit handles the rewording | |
| 12:39:23 | kashyap | aspiers: Now looking at your pastebin | |
| 12:39:23 | openstackgerrit | Adam Spiers proposed openstack/nova master: Track libvirt host/domain capabilities for multiple machine types https://review.opendev.org/673151 | |
| 12:39:24 | openstackgerrit | Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680 | |
| 12:39:24 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420 | |
| 12:39:25 | openstackgerrit | Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334 | |
| 12:39:25 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add |
|
| 12:39:26 | openstackgerrit | Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565 | |
| 12:39:26 | openstackgerrit | Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616 | |
| 12:42:02 | sean-k-mooney | aspiers: i like to use xpath for thinks like parseing the support device model enum. "/enum[@name='modelType']/value/text()" is much cleaner then looping over the child of my child that is a enm with a name atribute and then extraging alls its childerns text values | |
| 12:42:47 | aspiers | sean-k-mooney: yes but it depends on the context. config.py already has a top-down tree-based approach to iterating so in that context xpath makes no sense | |
| 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 | |