| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 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 | |
| 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 | |