| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 13:17:18 | efried | the way it works is this: | |
| 13:17:18 | efried | Some services do long-running operations, followed by other operations. Your user token may expire during the long-running operation, and then you would bounce on the subsequent operations. | |
| 13:17:18 | efried | So you set up [service_user] with ksa creds and that toggle you pointed out. | |
| 13:17:18 | efried | And we wrap your user token in what is effectively an admin token, which we then use if the user token expires. | |
| 13:17:30 | efried | Yeah, the stealth inclusion of ksa creds is easy to miss | |
| 13:17:50 | efried | so basically it looks like that conf only has one option, but it really has like a dozen -- all the ksa auth/session/adapter stuff. | |
| 13:18:14 | sean-k-mooney | ya i kind of glossed over the bottm of the file as i assume it was the normal boiler plate but looking at it now i see its not | |
| 13:18:25 | efried | So today you have to have that toggle switched on for us to even try loading up the ksa stuff. | |
| 13:18:43 | efried | if we turned off that toggle, we would try loading up the ksa stuff and if it fails just carry on with the user token as is | |
| 13:18:51 | efried | which is basically what we do today if you have the switch on anyway. | |
| 13:19:32 | efried | what's not clear is, if that toggle is gone, how should we behave if we can't load up the ksa bits? Just warn as we do today and carry on using the user token presumably | |
| 13:19:34 | sean-k-mooney | ya the context for this was there was a discussion downstream of if/when we will start supproting this in our product | |
| 13:19:56 | efried | but if the op doesn't *want* to use service auth, they're getting a warning for doing what they wanted. | |
| 13:20:21 | sean-k-mooney | efried: well i think the present of the service user in the config would be enough to singnel this no? | |
| 13:20:31 | sean-k-mooney | e.g. if you put it in the config we asssume you want to use it | |
| 13:20:37 | sean-k-mooney | if you didnt we assume you dont | |
| 13:20:55 | sean-k-mooney | is ther service_user section used for anythin else currently? | |
| 13:21:25 | sean-k-mooney | if so the toggle makes sense if not then its a needless extra step | |
| 13:21:55 | sean-k-mooney | but in anycase its not as simple as jsut enabling it by defualt. the operator need to add serveice_user creds | |
| 13:22:27 | efried | right, but it's a bit different than the other auth sections | |
| 13:22:29 | sean-k-mooney | i had asumeed we would reuse the admin creds that nova already has rather then accept a different set | |
| 13:22:46 | efried | The other ones, if you spell something wrong or mess up your creds, you can't do things. | |
| 13:22:52 | efried | With this one, we can still mostly operate. | |
| 13:23:04 | efried | so how should we behave if you put stuff in but f it up? | |
| 13:23:23 | sean-k-mooney | ya i get the concern about the silent failure | |
| 13:23:39 | efried | Really this is a question we should be addressing with what we have today anyway. | |
| 13:23:46 | sean-k-mooney | if you populated the filed and the password or whatever was wong i woudl expect an error | |
| 13:23:59 | efried | because IMO if you said "I want to do this thing" but we can't work with what you've entered, it should arguably be a failure. | |
| 13:24:03 | efried | right | |
| 13:24:08 | sean-k-mooney | but if you typo the section name that is tricker | |
| 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 | sean-k-mooney | so the installer would have to configure it | |
| 13:24:53 | efried | sean-k-mooney: other quirks and details to be aware of: | |
| 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 | |