| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 13:11:27 | kashyap | aspiers: At this point, no. | |
| 13:11:39 | sean-k-mooney | aspiers:for a uefi boot there would have to be a gpt partion on the image and it would need a efi boot partion to unpack the efi into | |
| 13:11:41 | efried | If the host needs uefi-ness, then that needs to be part of determining whether the host exposes the SEV capability and the MEM_ENC_CTX inventory. | |
| 13:11:47 | sean-k-mooney | i think | |
| 13:12:13 | aspiers | efried: every SEV host will support UEFI | |
| 13:12:34 | aspiers | efried: in fact I'm guessing also every host made in the last $NOT_SMALL years | |
| 13:12:51 | sean-k-mooney | basicaly uefi booth need (typically) a 1M partition for use by the uefi firmware. if that is not in the disk image then the firmeware suppoied by the host wont work | |
| 13:13:03 | aspiers | so it's not an issue for SEV, but it might be for hw_firmware_type in general | |
| 13:13:19 | aspiers | sean-k-mooney: thanks, that's extremely helpful | |
| 13:13:41 | aspiers | and also scary because it highlights that I might have no easy way of getting a UEFI-capable SLES image :-( | |
| 13:13:53 | sean-k-mooney | the only time i have used uefi with vms sofar i have installed from iso so it did the right thing | |
| 13:14:46 | sean-k-mooney | no idea if the cloud image are set up to work out of the box but i know disk image builder used to have issue with non msdos partion tables and i dont know if it can work wtih gpt partion tables yet so im guessing people milage will vary on this one | |
| 13:14:59 | efried | okay, so you can't just toggle that property on an image and expect it to work. | |
| 13:15:04 | efried | that answers the question, right? | |
| 13:15:19 | sean-k-mooney | you cant assuem it will work correct | |
| 13:15:24 | aspiers | right | |
| 13:15:30 | efried | then do the validation thingy | |
| 13:15:35 | aspiers | so yeah I'll follow sean-k-mooney's suggestion | |
| 13:15:38 | aspiers | thanks all | |
| 13:15:47 | efried | sean-k-mooney: re service auth... | |
| 13:16:49 | sean-k-mooney | efried: ya so looking at the config code i was not aware we had to expclitly set addtional credentials that were not alreday required | |
| 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:18 | efried | So you set up [service_user] with ksa creds and that toggle you pointed out. | |
| 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 | the way it works is this: | |
| 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 | 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 :-) | |