| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 10:01:15 | kashyap | aspiers: Probably somewhere surrounding here? https://review.opendev.org/#/c/640483/3/nova/virt/libvirt/config.py | |
| 10:02:41 | kashyap | (After I add the config class LibvirtConfigDomainCapsFirmwareEFI() or something like that) | |
| 10:03:03 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Use os-brick locking for volume attach and detach https://review.opendev.org/614190 | |
| 10:03:50 | aspiers | kashyap: I don't think there is any unmerged patch you need to depend on | |
| 10:04:17 | aspiers | kashyap: that patch you linked was merged ages ago | |
| 10:04:17 | kashyap | aspiers: Yep, just realized | |
| 10:05:53 | aspiers | kashyap: well, maybe https://review.opendev.org/#/c/673151/3 | |
| 10:06:01 | aspiers | which is the one I'm asking you to look at anyway :) | |
| 10:06:56 | kashyap | aspiers: Yeah, I have it open, and have half read the commit message, while I got 3 pings :D | |
| 10:07:04 | aspiers | hacking on nova feels a bit like wandering around a vast desert, and the experience of randomly bumping into someone else in the same vicinity is equally surprising | |
| 10:07:08 | kashyap | aspiers: Will spend time on it tooday, definitely | |
| 10:07:42 | aspiers | kashyap: just realised that maybe the subject of that commit is misleading | |
| 10:08:02 | aspiers | it's enhancing the parsing of *capabilities* not domain caps | |
| 10:08:34 | aspiers | the change regarding domain caps is that getDomCaps API gets called more often as a result (for the canonical machine types in addition to the default machine type for the arch) | |
| 10:09:34 | kashyap | aspiers: Hehe, mind you, we're in a mini desert in the "Cosmos of Nova" -- we're in HDD (Hypervisor Driver Desert) | |
| 10:09:37 | aspiers | If I change (only) a commit message and rebase the stuff on top, will Gerrit/Zuul re-run all the CI on an identical git tree? | |
| 10:09:48 | aspiers | true X-D | |
| 10:10:08 | kashyap | lyarwood: --^ | |
| 10:10:31 | kashyap | aspiers: I _think_ rebase will re-run the entire world's CI :-( But I have a faint voice in the head saying: "that has changed" | |
| 10:11:01 | aspiers | I fear you might be right | |
| 10:11:34 | aspiers | kashyap: so are there *any* docs on how to do UEFI boot in nova? | |
| 10:11:51 | aspiers | kashyap: surely there must be another way to find out than reading merged gerrit patches | |
| 10:11:57 | aspiers | even the release note is useless | |
| 10:12:26 | kashyap | aspiers: Not that I know of. I don't think not even in the config help text I guess. | |
| 10:12:34 | kashyap | aspiers: Does this count? -- https://opendev.org/openstack/nova-specs/src/branch/master/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst | |
| 10:12:37 | kashyap | :D | |
| 10:12:57 | kashyap | The part in the "Problem description" can account for _some_ documentation. /me ducks | |
| 10:14:12 | aspiers | hah | |
| 10:14:38 | aspiers | for SEV, I felt that if I didn't include insanely comprehensive docs with the patches, I would have no chance of getting it accepted | |
| 10:14:51 | aspiers | maybe that was a misperception | |
| 10:14:57 | aspiers | but I don't regret writing them, of course | |
| 10:15:34 | aspiers | kashyap: BTW http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html is a nicer rendering of the same | |
| 10:16:27 | kashyap | Ah, thank you | |
| 10:17:45 | kashyap | aspiers: On docs, don't worry -- if you've improved the 'void' (i.e. non-existent docs), then it definitely is worth accepting. | |
| 10:18:00 | kashyap | I don't guess anyone would have the gall to "not accept" those. | |
| 10:18:16 | kashyap | (Without a damn good reason) | |
| 10:18:22 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add delete_on_termination to volume-attach API https://review.opendev.org/673133 | |
| 10:19:12 | aspiers | kashyap: hah, I know you weren't doing this, but given the effort I spent on them, if anyone described the docs I've submitted as "they improved the void", that would feel like a slap in the face X-D | |
| 10:19:20 | aspiers | kashyap: check out https://review.opendev.org/#/c/666616/22/doc/source/admin/configuration/hypervisor-kvm.rst | |
| 10:19:42 | aspiers | and then press ']' twice for the other docs | |
| 10:19:59 | kashyap | aspiers: Yeah, sorry, as you guessed - I didn't target that at you at all. Was saying more in general | |
| 10:20:21 | kashyap | If anyone provides any docs that _improves_ the status quo, accept it, no ifs and buts. | |
| 10:20:45 | kashyap | aspiers: Oh, the ']' trick, I didn't know; thanks! | |
| 10:20:49 | aspiers | Well yeah, but if a new feature is submitted with sub-par docs, I'd argue that's *worsening* the docs | |
| 10:20:58 | aspiers | kashyap: press '?' for all shortcuts | |
| 10:21:19 | aspiers | they're almost all worth memorising | |
| 10:21:25 | kashyap | aspiers: Yeah, fugreed. BTW, excellent docs there, as usual: https://review.opendev.org/#/c/666616/22/doc/source/admin/configuration/hypervisor-kvm.rst | |
| 10:21:39 | kashyap | aspiers: I say not many developers have the discipline to write solid docs. | |
| 10:22:01 | aspiers | It's a shame. It's not the most fun thing to do, but damn is it satisfying once they're done | |
| 10:22:21 | aspiers | especially when all the subsequent questions you get can be answered with RTFM ;-) | |
| 10:22:47 | kashyap | Yes. Many many developers forget to realize that their "beautiful code" is not worth a damn if they don't spend a decent chunk of time describing the feature | |
| 10:23:12 | kashyap | Not a curt, crappy document. But a good one, that makes you feel "pain" when you write. And after some rounds of editing. | |
| 10:24:27 | kashyap | aspiers: BTW, I'll of course be writing a document for Sec Boot, collecting artefacts here: https://kashyapc.fedorapeople.org/Secure-Boot-for-KVM-QEMU-guests/ | |
| 10:24:52 | aspiers | great | |
| 10:25:16 | openstackgerrit | Huachang Wang proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 10:25:17 | aspiers | so, in the absence of TFM, please can you tell me how to configure UEFI boot? | |
| 10:25:44 | aspiers | even your SB spec problem description doesn't really cover it AFAICS | |
| 10:26:04 | aspiers | https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/boot-from-uefi.html sort of does | |
| 10:26:12 | aspiers | is hw_firmware_type=uefi enough? | |
| 10:26:59 | aspiers | oh I found it! https://docs.openstack.org/glance/pike/admin/troubleshooting.html#launch-instances-with-uefi | |
| 10:27:38 | aspiers | kashyap: unfortunately I am now being bitten by your decision not to +1 https://review.opendev.org/#/c/348394/, since I need this working on SLES 12 ... | |
| 10:29:22 | aspiers | I think it could have been a reasonable stop-gap solution | |
| 10:30:02 | kashyap | aspiers: Oh, speaking of which! | |
| 10:30:20 | aspiers | TBH I think it would still make sense to merge that, even at this late stage | |
| 10:30:31 | kashyap | Can you check with Dirk & co. on any progress on getting the JSON file descriptor files as part of SLES's EDK2/OVMF package? | |
| 10:30:38 | kashyap | I've written the patch for Fedora: | |
| 10:30:56 | aspiers | kashyap: I thought we connected you with Jim Fehlig on that front? | |
| 10:31:02 | aspiers | he's our OVMF expert | |
| 10:31:25 | kashyap | Yes, we did. I'll revive the thread with the example | |
| 10:31:38 | aspiers | and in fact he's the one who yesterday suggested that my SEV guest is broken because it wasn't booted with UEFI | |
| 10:31:44 | kashyap | See this example: https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8 | |
| 10:32:12 | kashyap | Please point it to Jim. Or I'll revive that thread post Denver with some more info | |
| 10:32:32 | kashyap | aspiers: I've filed similar RFE bugs for Debian and Ubuntu, too | |
| 10:32:39 | aspiers | I've found the old mail thread | |
| 10:32:56 | aspiers | May 8-10 | |
| 10:33:42 | kashyap | Right | |
| 10:35:23 | sean-k-mooney | kashyap: by the way changing the motherboard does not always cause windows to be reactivated or require reactivation. it depend on if its a retail copy or oem. oem copies are tied to the machine they are booted on retail are not. | |
| 10:35:34 | sean-k-mooney | *installed on | |
| 10:36:21 | kashyap | What is the difference between "retail copy" and "OEM"? | |
| 10:36:33 | sean-k-mooney | if the frimware/system uuid does not change i think it would not triger reactivation of windows licenes | |
| 10:37:13 | sean-k-mooney | kashyap: its a diffenet EULA and teh activation key is from a diffferent pool onther then that they are identical | |
| 10:37:18 | sean-k-mooney | oem key are cheaper | |
| 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 | |