| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 19:23:59 | mriedem | like, cats > dogs? | |
| 19:24:11 | dansmith | pizza > cookies | |
| 19:24:28 | mriedem | i'd agree with that | |
| 19:24:49 | mriedem | https://sallysbakingaddiction.com/chocolate-chip-cookie-pizza/ | |
| 19:24:56 | mriedem | a love child | |
| 19:28:39 | dansmith | mriedem: okay I'm not sure I get it | |
| 19:28:45 | dansmith | we have this set_host_enabled call already yeah? | |
| 19:29:05 | dansmith | and the base virt driver does what when you call it? raise not implemented? | |
| 19:29:11 | mriedem | yes, only used by the os-hosts api which was deprecated in 2.43 and only implemented by the xenapi driver | |
| 19:29:14 | mriedem | yes | |
| 19:29:39 | dansmith | oh, I see, different from service disable yeah? | |
| 19:29:43 | mriedem | yes, | |
| 19:29:48 | dansmith | right right, okay | |
| 19:29:49 | mriedem | but i'm going to use it for service disable/enable in the api change | |
| 19:29:56 | dansmith | yeah | |
| 19:29:57 | dansmith | so, | |
| 19:30:17 | dansmith | the thing you're concerned about is replicating the 501 "this thing doesn't support that" case for libvirt and v2.1? | |
| 19:30:38 | mriedem | it's a minor concern, but yeah | |
| 19:30:39 | dansmith | I guess I'm not sure why that matters.. the fact that libvirt does or doesn't support the thing has nothing to do with microversion 2.1 (or any version) | |
| 19:31:00 | mriedem | the version really only matters b/c the api no longer works with 2.43+ | |
| 19:31:06 | mriedem | for any driver | |
| 19:31:24 | dansmith | okay but.. why does it matter if someone calls it with v2.1 on libvirt and it works? | |
| 19:31:45 | mriedem | because it's a behavior change... | |
| 19:31:50 | dansmith | it's not | |
| 19:31:58 | dansmith | it's an implementation detail | |
| 19:32:14 | dansmith | if the thing (which the user can't see) supports it, it works, and if not it's 501 | |
| 19:32:40 | mriedem | or 400 if i just return None | |
| 19:32:41 | dansmith | they can't see that libvirt didn't support it before, got a 501, and that either now it does support it, or some other driver is being used | |
| 19:33:03 | mriedem | in this case the user == admin anyway, | |
| 19:33:08 | mriedem | so another reason why it's a minor concern for me | |
| 19:33:37 | dansmith | right, but this is not necessarily an admin user that has visibility into the hypervisor details | |
| 19:34:03 | dansmith | this could be a level-1 lab monkey that needs to disable a host to go blow dust out of the fans or something | |
| 19:34:51 | dansmith | anyway, just saying I don't think we should tie behavior of a microversion to a version of the implementation underneath when the behavior and semantics haven't changed | |
| 19:35:11 | mriedem | sure. if you don't think anything needs to change that's fine with me. would appreciate a comment in the review for if/when someone comes along saying it's a change. | |
| 19:35:19 | dansmith | will | |
| 19:35:19 | mriedem | also note the api ref is pretty clear to not use that api https://developer.openstack.org/api-ref/compute/?expanded=update-host-status-detail#update-host-status | |
| 19:46:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove unreachable native QEMU iSCSI initiator config code https://review.opendev.org/668750 | |
| 20:07:06 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add placement request pre-filter compute_status_filter https://review.opendev.org/668752 | |
| 20:42:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor HostAPI.service_update https://review.opendev.org/668756 | |
| 20:50:31 | melwitt | 'tpm_project_id' compute stat to the project_id when a tpm request lands on the host. and the 'tpm_project_id' stat gets cleared during init_host | |
| 20:50:31 | melwitt | efried, jroll, dansmith: fwiw, an idea we had when I chatted with penick about the TPM thing was tracking the "TPM availability" outside of placement using a scheduler filter and a new compute stat. the compute stat would be something like 'tpm_project_id' and defaults to None. and the scheduler filter passes a host only if 'tpm_project_id' is None or matches project_id [if a tpm is requested]. and then in nova-compute, set | |
| 20:51:53 | efried | melwitt: Except for that last bit. Having restarted the compute service does *not* mean the TPM is clear and ready for use by someone else. The only way we can know that bit is if the admin tells us so. | |
| 20:52:04 | melwitt | the only caveat I was thinking here is that init_host doesn't guarantee a reboot happened | |
| 20:52:13 | efried | just so | |
| 20:52:24 | efried | and a reboot doesn't guarantee the TPM was cleared. | |
| 20:52:24 | melwitt | yeah | |
| 20:52:43 | melwitt | oh, ok, I didn't know that or misunderstood | |
| 20:52:58 | sean-k-mooney | is there any reason we cant wipe the tpm directly when we delete a vm that is using it | |
| 20:53:05 | efried | a reboot is required, but not sufficient. You had to have done some kind of purgey command prior | |
| 20:53:13 | melwitt | sean-k-mooney: from what penick said, that is not possible | |
| 20:53:22 | melwitt | efried: I see | |
| 20:53:41 | sean-k-mooney | efried: is a reboot requried or can we do a device reset | |
| 20:53:57 | sean-k-mooney | i have not looked into it but i know fo bios based gpus a reboot was required | |
| 20:54:06 | efried | I don't know whether "purgey command" is "device reset" or what, but you have to reboot the host for it to be reusable. | |
| 20:54:07 | sean-k-mooney | for uefi based gpus a deivce reset was enough | |
| 20:54:28 | sean-k-mooney | it could depend on the type of tpm you have | |
| 20:54:40 | sean-k-mooney | there are several diffeerent tpm types | |
| 20:54:50 | sean-k-mooney | that are connect over different buses | |
| 20:54:50 | efried | how would we know? | |
| 20:56:05 | mriedem | sure sounds like hardware management that nova shouldn't be doing... | |
| 20:56:06 | sean-k-mooney | im not sure https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_implementations | |
| 20:57:03 | sean-k-mooney | i think descret tp0ms and maybe the integrated tpm in the intel chips set can be passthed through | |
| 20:57:15 | sean-k-mooney | the firware and software one obviosly cant be | |
| 20:57:45 | efried | mriedem, melwitt: in case y'all weren't silently following along, here's the earlier conversation with jroll and dansmith: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-02.log.html#t2019-07-02T17:30:56 | |
| 20:57:54 | mriedem | efried: i saw it | |
| 20:58:04 | mriedem | and agreed with the -5 comment | |
| 20:58:09 | efried | k | |
| 20:58:10 | melwitt | efried: yeah, I mentioned what I did bc I read it | |
| 20:58:16 | efried | k | |
| 20:58:36 | efried | thanks for the followup | |
| 20:58:37 | melwitt | at the very least for any potential downstream-only endeavor | |
| 20:59:46 | sean-k-mooney | i takeign booting windows to run the clear-tpm powershell commadn is not a thing we cand do :) https://docs.microsoft.com/en-us/powershell/module/trustedplatformmodule/clear-tpm?view=win10-ps | |
| 21:00:03 | sean-k-mooney | its rare that all the hits i get in google are for windows | |
| 21:00:26 | melwitt | if there were a way we could query the tpm device to know whether it's clear/ready, then IMO it seems similar enough to pci passthrough and not so bad | |
| 21:00:58 | melwitt | but since there's not, then I agree it doesn't fit | |
| 21:01:41 | sean-k-mooney | apparent there is a tpm_clear command | |
| 21:01:58 | mriedem | we have also done a poor job at times of tracking allocated pci devices | |
| 21:02:07 | sean-k-mooney | just reading https://resources.infosecinstitute.com/linux-tpm-encryption-initializing-and-using-the-tpm/#gref | |
| 21:02:10 | openstackgerrit | Merged openstack/nova stable/rocky: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.opendev.org/667436 | |
| 21:02:35 | mriedem | e.g. https://review.opendev.org/#/q/I6e871311a0fa10beaf601ca6912b4a33ba4094e0 | |
| 21:02:52 | melwitt | aye | |
| 21:03:33 | sean-k-mooney | it looks like clearing the tpm makes it unowned and disablses it which requries a reboot to fix | |
| 21:03:57 | melwitt | yeah, that's what efried was saying earlier. it's a two-step deal | |
| 21:06:04 | sean-k-mooney | ya diging a bit deeper it looks like linux cant actully clear teh tpm its self for security reason and its actully the uefi on reboot that is clearing it | |
| 21:06:25 | sean-k-mooney | so ya based on that i think this is a non starter | |
| 21:07:03 | sean-k-mooney | we we need to do is impove qemu to make vTPM more secure by not storign the encryption key on the host | |
| 21:07:19 | sean-k-mooney | perhaps by storign it in the host tpm | |
| 21:07:35 | sean-k-mooney | or barbacan or some other keystore | |
| 21:08:27 | melwitt | yeah, qemu enhancement is needed. I'm not sure if that's on their radar already. could ask kashyap maybe | |
| 21:09:39 | efried | it is | |
| 21:10:01 | efried | just not going to be ready in time for T | |
| 21:10:22 | melwitt | ah ok | |
| 21:31:55 | sean-k-mooney | efried: gibi so have we talked about how we handel move operations for the encryped image spec https://review.opendev.org/#/c/608696/8/specs/train/approved/image-encryption.rst@285 | |
| 21:32:51 | sean-k-mooney | i would be in faovr of supporting this as an experimenal feature without them but im hopping at least cold migraiton and live migration might work | |
| 21:33:07 | sean-k-mooney | rescue,shelve and cross cell resize might be tricker | |
| 21:33:25 | sean-k-mooney | if we have snapshot working it shoudl be possibel to support them however | |
| 21:33:41 | efried | sean-k-mooney: I wouldn't expect this to affect lifecycle operations | |
| 21:34:11 | efried | because the change is in the image processing layer | |
| 21:34:27 | sean-k-mooney | well for rescuse we are temporaily booting the instance with a different image but we still need to be able to decypt its disks | |
| 21:34:52 | efried | The disk is not encrypted at that point. | |