| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 02:51:06 | alex_xu | dansmith: if we are in the middle of upgrade, like Live migraiton, there will be have object transfer between new and old node. so for old node, it may have old os-resource-class lib, so it may not know the new RC, then the deserilzier will blowup. So if we want the validation, I think we only need a copy of generic RC pattern | |
| 02:51:08 | alex_xu | https://github.com/openstack/placement/blob/master/placement/schemas/common.py#L19, let me know if it is right | |
| 03:01:52 | openstackgerrit | Merged openstack/nova master: Use microversion in put allocations in test_report_client https://review.opendev.org/679622 | |
| 03:30:59 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API https://review.opendev.org/673485 | |
| 04:14:54 | gmann | melwitt: johnthetubaguy alex_xu looking for review/feedback on this first set of policy-defaults-refresh changes. This one and all its base patches - https://review.opendev.org/#/c/648480/ | |
| 04:15:36 | alex_xu | gmann: got it | |
| 04:16:04 | gmann | alex_xu: thanks. and this nit followup change in spec - https://review.opendev.org/#/c/669196/ | |
| 04:17:05 | gmann | alex_xu: this is review guide i sent on ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.html | |
| 04:17:46 | alex_xu | gmann: got it, I will give it try, let see if i have enough bandwidth | |
| 04:18:18 | gmann | alex_xu: thx again , kenichi has +2 on most of them i think | |
| 04:53:55 | openstackgerrit | Akira KAMIO proposed openstack/nova master: VMware: disk_io_limits settings are not reflected when resize https://review.opendev.org/680296 | |
| 05:40:59 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for Cyborg access https://review.opendev.org/631242 | |
| 05:41:00 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add Cyborg device profile groups to request spec. https://review.opendev.org/631243 | |
| 05:41:00 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Create and bind Cyborg ARQs. https://review.opendev.org/631244 | |
| 05:41:01 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.opendev.org/631245 | |
| 05:41:01 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Delete ARQs for an instance when the instance is deleted. https://review.opendev.org/673735 | |
| 05:53:01 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API https://review.opendev.org/673485 | |
| 06:46:13 | openstackgerrit | Luyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/679640 | |
| 06:46:14 | openstackgerrit | Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470 | |
| 06:46:14 | openstackgerrit | Luyao Zhong proposed openstack/nova master: doc: attaching virtual persistent memory to guests https://review.opendev.org/680300 | |
| 07:02:24 | brinzhang | gmann: takashin: https://review.opendev.org/#/c/673133/15/api-ref/source/os-volume-attachments.inc@46, replace the response of the `GET os-volume_attachments`` or ``SHOW os-volume_attachments`` response body by latest version. | |
| 07:02:33 | brinzhang | gmann: takashin: I am not sure is it appropriate. If the microversion less than 2.78, the delete_on_termination field will not contained in the response. | |
| 07:02:50 | brinzhang | gmann: takashin:In PS12 I also add the v2.78 response example to that palce, but mriedem let me removed it and just add the os-volume_attachments response to the POST API. https://review.opendev.org/#/c/673133/12/api-ref/source/os-volume-attachments.inc@54 | |
| 07:09:28 | takashin | brinzhang: If the microversion less than 2.78, the delete_on_termination field will not contained in the response. But it is not problem because the parameter description says delete_on_termination has been added since microversion 2.78. | |
| 07:14:20 | brinzhang | takashin: thanks, I will replace it by follow-up. | |
| 07:47:35 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/621646 | |
| 07:58:02 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.opendev.org/649963 | |
| 07:58:02 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Fix live migration break group policy simultaneously https://review.opendev.org/651969 | |
| 08:07:59 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API https://review.opendev.org/673485 | |
| 08:34:00 | openstackgerrit | Yongli He proposed openstack/nova master: Clean up orphan instances virt driver https://review.opendev.org/648912 | |
| 08:34:01 | openstackgerrit | Yongli He proposed openstack/nova master: clean up orphan instances https://review.opendev.org/627765 | |
| 08:41:42 | kashyap | aspiers: This is from OpenSUSE, see the maddenning number of OVMF binaries :-( -- http://paste.openstack.org/show/693648/ | |
| 08:41:46 | kashyap | aspiers: An impressive 35 | |
| 08:42:54 | kashyap | aspiers: Anyway, can you get the same output from SLES? (`rpm -ql qemu-ovmf-x86_64`) | |
| 08:44:09 | kashyap | aspiers: But my educated guess is that, these two are the recommended ones for Secure Boot: | |
| 08:44:12 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-code.bin | |
| 08:44:14 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin | |
| 08:44:27 | kashyap | (The above are from OpenSUSE. Hopefully they're similarly named on SLES.) | |
| 08:45:20 | kashyap | aspiers: In short, for SB, you want the 'ms'-variant '-code.bin' (and its corresponding '-vars.bin') | |
| 08:46:26 | aspiers | kashyap: it's not 35, you're counting text files and directories in that | |
| 08:46:38 | aspiers | kashyap: but still agree that it's way too many | |
| 08:46:51 | kashyap | aspiers: Yeah, sorry, exaggerated; do rake me on coals | |
| 08:46:54 | aspiers | XD | |
| 08:47:20 | aspiers | It's the same on SLES | |
| 08:52:45 | dr_gogeta86 | good morning | |
| 08:52:58 | dr_gogeta86 | any hitachi guys here ? | |
| 08:58:03 | kashyap | aspiers: Okay, then. Do you have the recorded notes from your previous successful Secure Boot? | |
| 08:58:21 | kashyap | aspiers: If so, I'd bet they are the ms-variant binaries. | |
| 08:58:50 | aspiers | kashyap: No it was -suse-code | |
| 08:59:55 | kashyap | aspiers: Ah, okay. So they are the MS-enrolled ones for SLES | |
| 09:00:11 | aspiers | kashyap: But the problem is I'm trying to boot an unreleased test kernel | |
| 09:00:18 | aspiers | so it doesn't have the official signature | |
| 09:01:00 | kashyap | Nod; for this unrelease kernel, either you just go into the Tianocore BIOS and disable SB | |
| 09:01:20 | aspiers | kashyap: https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel has been suggested | |
| 09:01:53 | kashyap | Yep, those are the steps the Secure Boot / BIOS dev I know recommended too | |
| 09:02:05 | kashyap | You have to do a lot of manual muckery, generate certs, run 'mokutil', etc | |
| 09:03:12 | aspiers | kashyap: do BIOS definitions get persisted to the VARS file? is that what https://review.opendev.org/#/c/621646/ is about? | |
| 09:04:11 | aspiers | kashyap: I'm confused by that commit, because even without it I *already* see the vars files persisting in /var/lib/libvirt/qemu/nvram | |
| 09:04:26 | kashyap | aspiers: The VARS file contains anything a user configures. | |
| 09:04:28 | aspiers | Oh, that's the bug | |
| 09:04:54 | kashyap | aspiers: The context is: just like traditional BIOS, UEFI has menus (just more of them), and needs to store them somewher | |
| 09:04:55 | aspiers | "Anything" meaning what though? BIOS settings? anything else? | |
| 09:05:10 | kashyap | So, if a user customizes something, it goes into the "VARS" file | |
| 09:06:00 | kashyap | aspiers: One of the things it stores is the UEFI keys | |
| 09:07:45 | kashyap | aspiers: Yeah, the bug is reinitializing a VARS from the default template, which is is undesirable. | |
| 09:08:51 | aspiers | right | |
| 09:09:00 | aspiers | so e.g. SB would have to be disabled every boot | |
| 09:09:19 | aspiers | there should really also be some way to change the default template | |
| 09:09:23 | aspiers | even per image | |
| 09:10:10 | kashyap | aspiers: In what else way do you want to "change the default (VARS) template"? | |
| 09:10:34 | aspiers | e.g. disabling SB | |
| 09:10:45 | aspiers | or any other BIOS tweak you can imagine | |
| 09:11:46 | kashyap | You don't want to mess with the default template itself, but rather do what libvirt does -- copy it per guest, in the "domain private path", and _then_ do what you want | |
| 09:12:06 | kashyap | aspiers: If you _don't_ want SB, then simply use the un-enrolled VARS file. | |
| 09:12:14 | aspiers | How? | |
| 09:12:28 | aspiers | I guess I didn't explain the use case clearly enough | |
| 09:12:38 | aspiers | Let's say I want to boot 100 VMs with SB, and another 100 without SB | |
| 09:12:41 | aspiers | How do I do that? | |
| 09:12:59 | kashyap | This way: | |
| 09:13:48 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is built with SB/SMM (i.e. suse-code.bin) | |
| 09:14:24 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is *not* with SB/SMM (i.e. suse.bin -- or whatever it's called) | |
| 09:14:30 | aspiers | But as an unprivileged non-admin how do I choose which OVMF binary gets used? | |
| 09:15:07 | kashyap | (Both the above is for UEFI boot, though.) | |
| 09:15:12 | kashyap | aspiers: So for a non-admin uesr: | |
| 09:15:36 | kashyap | You simply _don't_ set the 'uefi' image property | |
| 09:15:52 | aspiers | No, because then SEV breaks | |
| 09:16:13 | kashyap | Ah! We're talking in SEV context | |
| 09:16:17 | aspiers | Of course :) | |
| 09:16:24 | aspiers | Well, just as an example | |
| 09:16:28 | kashyap | Forgot the world spins around SEV for a sec :D | |
| 09:16:39 | aspiers | It's one example of a more general issue | |
| 09:16:58 | aspiers | What if I want to boot 100 VMs with some UEFI option tweaked and 100 with it not tweaked? It's not always going to be the case that there's a binary offering exactly what I want; there should be an option to create custom VARS templates, and to choose which VARS template to start from | |
| 09:17:04 | kashyap | aspiers: Now the question is: why would you want SEV *without* SB? | |
| 09:17:24 | aspiers | Well I already gave yesterday's example: testing new unsigned kernels | |
| 09:17:48 | aspiers | but please don't get hung up on the SEV part, that's just one example | |
| 09:18:00 | kashyap | Sure, sure. | |
| 09:18:17 | aspiers | It seems entirely reasonable to assume that at some point hardly anyone will want to boot non-UEFI | |
| 09:18:35 | kashyap | aspiers: For enrolling your own VARS files, the process is not "simple" :-( | |
| 09:18:48 | aspiers | and even though maybe most people will want SB and other default UEFI options most of the time, I'm sure they will want non-defaults at other times | |
| 09:19:09 | kashyap | E.g. to enroll _default_ UEFI (MS) keys (which most distros ship now), we wrote this tool: https://github.com/puiterwijk/qemu-ovmf-secureboot | |