| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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 | |
| 01:21:45 | openstackgerrit | Merged openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.opendev.org/629597 | |
| 02:06:59 | openstackgerrit | Merged openstack/nova stable/queens: libvirt: Avoid using os-brick encryptors when device_path isn't provided https://review.opendev.org/656464 | |
| 06:17:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Introduce live_migration_claim() https://review.opendev.org/635669 | |
| 06:17:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 06:17:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | |
| 06:17:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.opendev.org/634828 | |
| 06:17:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 06:17:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | |
| 06:17:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: CONF.enable_numa_live_migration is not needed >= Train https://review.opendev.org/640021 | |
| 07:02:59 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.opendev.org/621476 | |
| 07:25:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Stabilize unshelve notification sample tests https://review.opendev.org/668806 | |
| 07:34:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Get rid of args to RBDDriver.__init__() https://review.opendev.org/668564 | |
| 07:52:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove unreachable native QEMU iSCSI initiator config code https://review.opendev.org/668750 | |
| 08:37:32 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.opendev.org/649963 | |
| 08:47:40 | kashyap | johnthetubaguy: You about by any chance? If so, the Secure Boot spec requires the final +2 (& a +W), assuming you're satisfied with all the things I've addressed: https://review.opendev.org/#/c/506720/ | |
| 09:57:28 | kashyap | alex_xu: Hi, maybe you can give the final ACK (if you don't spot anything else): https://review.opendev.org/649963 | |
| 11:23:34 | openstackgerrit | Josephine Seifert proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption https://review.opendev.org/608696 | |
| 11:26:32 | Luzi | sean-k-mooney, I added a few sentences concerning the lifecycle | |
| 11:56:30 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |