| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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. | |
| 21:35:04 | efried | this isn't like LUKSing the boot disk. | |
| 21:35:06 | sean-k-mooney | and for shelve/cross cell resize we need to ensure we create encrypted snapshots for encrypted instances | |
| 21:35:24 | efried | This is encrypting it in glance. It gets decrypted when it's copied into the instance's storage. | |
| 21:35:39 | sean-k-mooney | the instaces storage is also encrypted | |
| 21:35:49 | sean-k-mooney | its not stored decyped on the compute node | |
| 21:35:56 | efried | um | |
| 21:36:03 | efried | then I wildly misunderstood the spec | |
| 21:36:39 | sean-k-mooney | "Using encrypted storage backends for volume and compute hosts in conjunction | |
| 21:36:41 | sean-k-mooney | with direct data transfer from/to encrypted images can enable workflows that | |
| 21:36:43 | sean-k-mooney | never expose an image's data on a host's filesystem. | |
| 21:36:45 | sean-k-mooney | " | |
| 21:37:01 | efried | right, but "using encrypted storage backends" is not part of this spec | |
| 21:37:06 | efried | that's already supported | |
| 21:38:29 | sean-k-mooney | right but that means on the host the iamge is still encrypted as its streamed into an encpted file | |
| 21:39:12 | sean-k-mooney | so when you do a nova rescue and you boot form a different image you still need to pass the encyption key to qemu so it can open that encypted file a use it | |
| 21:39:26 | efried | Not "still encrypted". decrypted to clear, then re-encrypted with a different key (and possibly a different algorithm, etc) | |
| 21:40:09 | efried | so yes, *if* your storage backend is encrypted, regardless of whether you're using *image* encryption (this feature), then you'll need to manage slinging keys around. | |
| 21:40:15 | sean-k-mooney | the decypted to clear happens in memory. but when i was referign to still encrypted i ment after it was re encrypted | |
| 21:40:31 | efried | I'm saying they're separate and unrelated. | |
| 21:40:33 | sean-k-mooney | ok so long as that all works that is cool | |
| 21:40:39 | efried | I think | |
| 21:40:50 | sean-k-mooney | i just was suprised that it was never mention in the spec | |
| 21:43:44 | sean-k-mooney | i could cahcne my +1 to a -1 i guess until josephine seifert replies to confirm but i whould have expect this to at least be mentioned in the spec if all it was is "it jsut works" | |
| 22:12:27 | mriedem | dansmith: you know how this set_host_enabled is a blocking rpc call? if this is an ironic compute service managing 1000 compute nodes (1000 resource providers) and we have to sync the trait on all of them, i'm not sure if that would take more than 60 seconds but it might - thinking this change should use the long_rpc_timeout for that call now - agree? | |
| 22:21:27 | mriedem | weee looks like the gate is crapping itself too atm | |
| 22:23:00 | openstackgerrit | Merged openstack/nova-specs master: Policy Default Refresh spec https://review.opendev.org/547850 | |
| 22:26:24 | dansmith | mriedem: yeah makes sense to make it a long rpc call | |
| 22:26:55 | dansmith | mriedem: even for the single compute case, if placement is bogged or something, we could still take a while to set the trait | |
| 22:31:13 | openstackgerrit | Merged openstack/nova stable/queens: Restore connection_info after live migration rollback https://review.opendev.org/662471 | |
| 22:35:54 | mriedem | melwitt: can you hit this remaining queens backport? https://review.opendev.org/#/c/629597/ | |
| 22:47:51 | openstackgerrit | Merged openstack/nova-specs master: Spec: Use OpenStack SDK in Nova https://review.opendev.org/662881 | |
| 22:50:06 | sean-k-mooney | heh if only the rest of the repo had a 10 minute merge trun around time | |
| 23:06:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Sync COMPUTE_STATUS_DISABLED from API https://review.opendev.org/654596 | |
| 23:07:15 | mriedem | it is done https://review.opendev.org/#/q/topic:bp/pre-filter-disabled-computes+(status:open+OR+status:merged) | |
| 23:08:23 | openstackgerrit | Merged openstack/nova-specs master: Libvirt: add vPMU spec for train https://review.opendev.org/651269 | |
| 23:09:25 | sean-k-mooney | mriedem: as in you have split it out int different patches and its now ready for review? | |
| 23:09:33 | mriedem | hells yeah | |
| 23:09:37 | mriedem | it's glorious | |
| 23:10:16 | sean-k-mooney | cool im poking at similar code for my own prefilter stuff so ill see if ther are any trick i shoudl "borrow" form my onw stuff | |
| 23:10:58 | sean-k-mooney | mriedem: did you drop the custom trait stuff since os-tratis 1.15 is released | |
| 23:11:03 | mriedem | yes | |
| 23:11:08 | mriedem | technically efried did that for me | |
| 23:11:21 | sean-k-mooney | cool | |
| #openstack-nova - 2019-07-03 | |||
| 00:40:10 | melwitt | alex_xu: hey, would appreciate to have your thoughts on the unified limits spec around the proxy API/deprecation and migration parts https://review.opendev.org/602201 | |
| 00:40:36 | melwitt | *especially the proxy API/deprecation and migration parts | |
| 00:45:24 | openstackgerrit | Merged openstack/nova stable/rocky: Init HostState.failed_builds https://review.opendev.org/668520 | |
| 00:45:31 | openstackgerrit | Merged openstack/nova master: Stabilize unshelve notification sample tests https://review.opendev.org/668675 | |