| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 13:24:09 | efried | but that's a separate discussion I think. | |
| 13:24:22 | sean-k-mooney | ok | |
| 13:24:30 | sean-k-mooney | you ansered my question anyway | |
| 13:24:47 | sean-k-mooney | its not as simple as just truning it on and it working | |
| 13:24:53 | efried | sean-k-mooney: other quirks and details to be aware of: | |
| 13:24:53 | sean-k-mooney | so the installer would have to configure it | |
| 13:25:07 | efried | it only applies to some services | |
| 13:25:19 | efried | like, ironic is always admin, so service auth is n/a | |
| 13:25:24 | efried | glance is always user, and it applies there | |
| 13:25:25 | sean-k-mooney | yes appreent glance can recive teh service token but not send it | |
| 13:25:30 | efried | neutron is *sometimes* admin | |
| 13:25:59 | efried | why would glance need to send a service token? | |
| 13:27:17 | sean-k-mooney | i was not sure about that either but appreently it has something to do with the glance_store. im guessint its related to there replication/validation capablities | |
| 13:27:52 | sean-k-mooney | efried: oh it for when glance it using cinder/swift as a backend | |
| 13:27:54 | sean-k-mooney | https://review.opendev.org/#/c/526611/ | |
| 13:28:53 | efried | okay, well, that sounds like an issue for glance to deal with then. | |
| 13:29:00 | sean-k-mooney | anyway our glance folks downstream mentioned that there are still somthing related to the glance_store drivers | |
| 13:29:06 | sean-k-mooney | ya is not a nova problem | |
| 13:29:21 | sean-k-mooney | well it could be for shelve | |
| 13:29:46 | sean-k-mooney | e.g. we send glance the user and service token but it might just use teh user token and fail | |
| 13:30:08 | sean-k-mooney | anyway tl;dr there is still work to do in some services | |
| 14:02:12 | aspiers | kashyap: libvirtError: operation failed: unable to find any master var store for loader: /usr/share/OVMF/OVMF_CODE.fd | |
| 14:02:28 | aspiers | I made that file a symlink to /usr/share/qemu/ovmf-x86_64-code.bin | |
| 14:02:41 | aspiers | where is the master var store supposed to live? | |
| 14:02:50 | aspiers | biab | |
| 14:05:21 | sean-k-mooney | <os> | |
| 14:05:23 | sean-k-mooney | <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> | |
| 14:05:25 | sean-k-mooney | <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> | |
| 14:05:27 | sean-k-mooney | <nvram>/var/lib/libvirt/qemu/nvram/ovn1_VARS.fd</nvram> | |
| 14:05:29 | sean-k-mooney | <boot dev='hd'/> | |
| 14:05:31 | sean-k-mooney | </os> | |
| 14:05:33 | sean-k-mooney | aspiers: ^ | |
| 14:06:00 | sean-k-mooney | i think you are missing the per vm VARs file | |
| 14:06:07 | sean-k-mooney | i belive its generated form a template | |
| 14:06:12 | sean-k-mooney | but i know know where that lives | |
| 14:06:43 | sean-k-mooney | aspiers: but kashyap will be able to point you in the right direction when he is back | |
| 14:35:30 | mriedem | forbidden aggregates must have jumped the runways queue https://etherpad.openstack.org/p/nova-runways-train | |
| 14:37:57 | mriedem | looks like brin zhang updated the runways but didn't log the changes | |
| 14:38:02 | mriedem | brinzhang_: ^ | |
| 14:39:42 | kashyap | aspiers: Yeah, you should have a corresponding VARS file | |
| 14:40:15 | kashyap | aspiers: On SLES, it is this combination: | |
| 14:40:29 | kashyap | - Firmware binary: /usr/share/qemu/ovmf-x86_64-opensuse-code.bin | |
| 14:40:41 | kashyap | - Matching variable store template: /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin | |
| 14:42:01 | kashyap | aspiers: Make the last file on SLES as a symlink to '/usr/share/OVMF/OVMF_VARS.fd'. Then your instance should launch. | |
| 14:42:54 | mriedem | well i think i unborked the runways queue etherpad | |
| 14:51:13 | sean-k-mooney | it was broken? | |
| 14:51:29 | sean-k-mooney | i had it open in a tab and it more or less looks the same | |
| 14:53:43 | aspiers | kashyap: thanks! | |
| 14:59:02 | kashyap | aspiers: When you get around to it, let me know if that works for you :-) | |
| 14:59:18 | aspiers | kashyap: trying right now | |
| 14:59:25 | kashyap | Okay; /me --> call | |
| 14:59:30 | aspiers | but I don't know if my image is really UEFI | |
| 14:59:37 | aspiers | any easy way to check? | |
| 15:01:22 | kashyap | aspiers: Yes: | |
| 15:01:59 | aspiers | kashyap: I assume I want /usr/share/qemu/ovmf-x86_64-suse-vars.bin since this is SLES not openSUSE | |
| 15:02:17 | kashyap | aspiers: Yes, run `tree efi` on /boot on your VM image | |
| 15:02:39 | aspiers | you mean after mounting it with qemu-nbd or libguestfs? | |
| 15:03:58 | kashyap | If your VM image is EFI-capable, then you'll see files with .efi extension (e.g. BOOTX64.EFI) under /boot/efi | |
| 15:04:21 | aspiers | thanks | |
| 15:04:45 | kashyap | Let me show you on Fedora - comparing an image that is not UEFI-capable with one that is | |
| 15:06:00 | kashyap | aspiers: (And yes, after mounting) | |
| 15:06:20 | kashyap | I use `guestmount`. | |
| 15:06:24 | aspiers | still getting Instance failed to spawn: libvirtError: operation failed: unable to find any master var store for loader: /usr/share/OVMF/OVMF_CODE.fd | |
| 15:06:43 | aspiers | lrwxrwxrwx 1 root root 41 Jul 29 04:22 OVMF_CODE.fd -> /usr/share/qemu/ovmf-x86_64-suse-code.bin | |
| 15:06:45 | aspiers | lrwxrwxrwx 1 root root 41 Jul 29 04:22 OVMF_VARS.fd -> /usr/share/qemu/ovmf-x86_64-suse-vars.bin | |
| 15:07:19 | kashyap | aspiers: Here is the comparison: http://paste.openstack.org/show/755075/ | |
| 15:07:51 | mriedem | https://review.opendev.org/#/c/621476/50 needs a lot of work... | |
| 15:08:47 | kashyap | aspiers: Let's try one more thing: | |
| 15:09:41 | mriedem | gmann: new compute api policy naming discussion in https://review.opendev.org/#/c/621476/50/nova/policies/server_topology.py@20 | |
| 15:10:00 | mriedem | i did my best to recommend names | |
| 15:10:19 | kashyap | aspiers: Let's try one more thing: can you post your /etc/libvirt/qemu.conf? | |
| 15:10:32 | kashyap | In short, if you _don't_ have this entry, add it in there: | |
| 15:10:33 | kashyap | nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" | |
| 15:10:35 | aspiers | sure | |
| 15:10:37 | kashyap | ]] | |
| 15:10:55 | aspiers | it's commented out | |
| 15:11:49 | kashyap | aspiers: Can you uncomment both the VARS, and CODE file out, restart libvirtd & try? | |
| 15:11:59 | aspiers | sure | |
| 15:12:06 | aspiers | except the commented bit is wrong | |
| 15:12:49 | kashyap | [This is test-only; note that long longer libvirt upstream intends to get rid of this config.] | |
| 15:13:05 | efried | mriedem: IMO runways shouldn't be limited to "ready for core review". What does that even mean? Code complete and passing tests should be sufficient. Are you saying they should be required to have so many rounds of non-core reviews before being eligible? That doesn't sound workable to me. | |
| 15:13:33 | efried | mriedem: (this is without having looked at the patch that triggered your comment btw, maybe it was marked WIP or not passing zuul, which would be valid reasons to keep it out of runways) | |
| 15:14:38 | efried | "obviously a mess" (my words, not yours) is super subjective. obviously you'll set a much higher bar than an inexperienced contributor. | |
| 15:14:59 | kashyap | aspiers: Note that in the 'nvram' libvirt config, you can give SUSE's precise file paths. (Symlinks should work too, of course) | |
| 15:15:40 | aspiers | kashyap: ack | |
| 15:25:16 | aspiers | kashyap: progress!! | |
| 15:25:28 | aspiers | kashyap: now I can see the vnc console and a kernel panic X-D | |
| 15:25:32 | aspiers | that's huge progress | |
| 15:25:56 | mriedem | efried: where did i say "obviously a mess"? | |
| 15:26:02 | mriedem | oh nvm, | |
| 15:26:03 | mriedem | i didn't | |
| 15:26:21 | efried | mriedem: yeah, I was kind of putting words in your mouth, sorry about that. | |
| 15:27:08 | mriedem | as for not really ready for core review, i removed that. it'd be nice if contributors from large companies that have other developers working on this project would do some peer review before putting stuff into runways, but i guess that's a pipe dream. | |
| 15:27:11 | aspiers | kashyap: that kinda gives me hope this whole thing might actually work :) | |
| 15:27:15 | mriedem | but i mean, there were just typos all over the thing | |
| 15:27:29 | mriedem | so i consider that not really ready for core review | |
| 15:27:41 | aspiers | mriedem: I really hope to do more "selfless" upstream work (including reviews) but right now I'm battling this SEV deadline | |
| 15:27:55 | mriedem | aspiers: ok? | |
| 15:28:11 | cdent | mriedem: pretty soon having reviewers at all will be a pipe dream | |
| 15:28:25 | sean-k-mooney | dont we already have a requirement that code must not be in WIP state to enter the runways | |