Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-20
22:09:40 efried sean-k-mooney: right, but the answer to "evacuate doesn't help you with ephemeral root disk" is "use volume/ceph".
22:10:09 sean-k-mooney and here its use barbican
22:10:10 efried with a vTPM the answer to "evacuate doesn't help you with ephemeral root disk" is "you better have a very recent snapshot of your vTPM"
22:10:15 efried no
22:10:24 efried barbican only stores the key used to unlock the file we've been discussing.
22:10:31 efried said file will be stored in swift
22:10:35 efried but only during snapshot
22:10:42 sean-k-mooney sure but as a user you can also store keys your self in barbican
22:10:49 efried how does that help?
22:10:57 efried you mean if you want to not use a vTPM at all?
22:11:14 sean-k-mooney use the tpm as a local secure cache fo the key
22:11:24 sean-k-mooney if you evacuate retive the backup form barbican
22:11:25 efried if barbican is secure enough for you, you would just use barbican.
22:11:43 efried though arguably you're counting on that ultimately here anyway.
22:11:45 sean-k-mooney you dont want to transfer it over the network everythime you boot
22:11:56 efried we're doing that anyway.
22:12:02 sean-k-mooney well ya
22:12:19 sean-k-mooney i was just going to say you have to do that to unlock the vtpm
22:12:27 efried Also I believe "VM talks to barbican" is a thing we're avoiding
22:12:36 efried limiting to "host talks to barbican"
22:13:10 sean-k-mooney barbican is a top level openstack sericve so worklaods can use it if they want too
22:13:16 efried if they want to, yes.
22:13:30 efried but it's the openstack user's credentials as opposed to $random_vm_user
22:13:46 sean-k-mooney oh yes that is what i ment by vm
22:13:48 efried and also I imagine there are reasons for the VM to be blocked from the keymgr service network-wise.
22:13:49 sean-k-mooney sorry
22:13:58 sean-k-mooney i ment application in the vm
22:15:28 sean-k-mooney anyway i think a resonable alternitive is if you need the keys to sruvice beyond the life time of the vm or be shared in a "sercure" way store them in barbican
22:15:57 sean-k-mooney if you you can tollerate losing the key in a evacuate case then your can store it soly in the tpm
22:16:44 sean-k-mooney dansmith: you primary concern is we loose the key used to encyrpt the os drive and loose data right if we loos the vtpm
22:16:52 sean-k-mooney wyoud ^ not solve that issue
22:17:10 sean-k-mooney *would
22:18:37 efried resize does a destroy and then a spawn?
22:19:02 sean-k-mooney it will redefine the domain but you dont loose data
22:19:11 sean-k-mooney and it may change host
22:20:03 sean-k-mooney e.g. if you resize form a flavor with 10G root disk to one with 20 it will grow the disk file
22:20:17 sean-k-mooney and if its libvirt the partion table and filesystem if it can
22:20:52 sean-k-mooney so we would have to copy the vtpm file if we move host
22:21:06 efried yeah, I'm exploring corner cases with the vTPM. If your resize adds/removes a vTPM where it was previously absent/present, that's fine. If both old & new flavor have the same version/model, we should carry the data. If they have a different version/model...?
22:21:07 sean-k-mooney if its to the same host we shoudl not need to do anything
22:21:39 sean-k-mooney if they are different models i would expect you to loose the contents of the tpm
22:21:52 sean-k-mooney unless we block that intentionally
22:22:08 efried yes to the first, the second is the question.
22:22:25 efried there's no way to persist the data, period. The versions/models are incompatible.
22:23:04 sean-k-mooney ya that is proably true or at least involved to do so i would not try in v1 of this
22:23:31 sean-k-mooney there might be a way to convert but im not aware of one off the top of my head
22:24:12 efried sean-k-mooney: not without introspecting, which ain't my business.
22:24:30 sean-k-mooney swtpm might have a fucntion to do it
22:24:49 sean-k-mooney but ya unless libvirt support it i think its out of scope
22:24:55 efried so I'm gonna say don't block it, cause who am I to say you didn't mean to do it
22:25:29 sean-k-mooney that would be my feeling too
22:25:51 sean-k-mooney we shoudl documetn it i guess
22:26:02 efried doing that now
22:26:21 sean-k-mooney but i dont think we shoudl guard in code against all pebcak errors
22:26:29 efried agreed
22:27:29 efried hmph, the thing about saving the swift ID in instance sysmeta has a problem code flow-wise.
22:27:48 efried because the driver is the thing that knows the vdev is in this particular file path
22:27:59 efried but the only thing we've asked the driver to do is snapshot.
22:28:19 efried and (I think) the driver can't tell if it's being asked to snapshot as part of a shelve or backup or...
22:28:47 sean-k-mooney am im not 100% sure about that last part
22:29:04 efried so I guess it could edit the sysmeta itself... but if it's not a shelve and the compute mgr is about to blow away the instance, the compute mgr needs a way to get that information so it can stuff it into the image meta.
22:29:13 efried I guess it can pull it from the instance
22:29:43 efried so the contract with the virt driver's snapshot method has to spell out where & how this info is stored in the sysmeta.
22:30:29 sean-k-mooney we create snapshot for shelve but i dont think the compute magener actully calls snapshot as part of that flow i think its donw by the driver
22:30:47 efried eh?
22:30:49 sean-k-mooney that said i could be way off base there so im checking
22:30:56 efried compute manager's shelve calls driver's snapshot
22:31:24 sean-k-mooney oh ok
22:31:31 efried https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L5911
22:32:32 sean-k-mooney ya your right i though we had a shelve fucntion on the driver interface that we called but this is handeled in the compute manager instead
22:33:30 sean-k-mooney so snapshot is passed the instace so it can get the flavor and image metadata
22:33:58 sean-k-mooney so the snapshot function can check if the isntace has a vtpm and directly update the system metadata as you said
22:34:14 sean-k-mooney oh right but it would not know if its a shleve or not
22:36:00 sean-k-mooney oh it can jsut check the instance.task_state right?
22:36:38 efried could, but compute mgr has to be able to peel it out anyway, so it's simpler if snapshot just always behaves the same and compute mgr pulls the info out of the sysmeta if it needs it.
22:37:14 sean-k-mooney ok
22:37:53 sean-k-mooney anyway night all o/
22:46:34 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Integrating with unified limits https://review.opendev.org/615180
23:09:16 openstackgerrit John Garbutt proposed openstack/nova master: Better policy unit tests https://review.opendev.org/657697
23:17:55 efried argh, destroy_disks=True is no longer sufficient grounds to delete the barbican key :(
23:18:28 efried In fact, I'm not sure we can "ever" do that.
23:51:05 openstackgerrit Eric Fried proposed openstack/nova-specs master: Spec: Ussuri: Encrypted Emulated Virtual TPM https://review.opendev.org/686804
23:51:38 efried phew. dansmith sean-k-mooney TxGirlGeek ^
23:51:45 efried and jroll
#openstack-nova - 2019-11-21
00:06:38 openstackgerrit Dustin Cowles proposed openstack/nova-specs master: Update provider config spec for identification conflicts https://review.opendev.org/693414
00:42:50 openstackgerrit Merged openstack/nova stable/train: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695145
01:11:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle target host cross-cell cold migration in conductor https://review.opendev.org/642591
01:11:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Validate image/create during cross-cell resize functional testing https://review.opendev.org/642592
01:11:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Add zones wrinkle to TestMultiCellMigrate https://review.opendev.org/643450
01:11:13 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for cross-cell finish_resize failing https://review.opendev.org/643451
01:11:13 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for prep_snapshot_based_resize_at_source failing https://review.opendev.org/669013
01:11:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Add confirm_snapshot_based_resize_at_source compute method https://review.opendev.org/637058
01:11:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Add ConfirmResizeTask https://review.opendev.org/637070
01:11:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Add confirm_snapshot_based_resize conductor RPC method https://review.opendev.org/637075
01:11:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Confirm cross-cell resize from the API https://review.opendev.org/637316
01:11:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Add revert_snapshot_based_resize_at_dest compute method https://review.opendev.org/637630
01:11:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Deal with cross-cell resize in _remove_deleted_instances_allocations https://review.opendev.org/639453
01:11:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Add finish_revert_snapshot_based_resize_at_source compute method https://review.opendev.org/637647
01:11:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Add RevertResizeTask https://review.opendev.org/638046
01:11:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Add revert_snapshot_based_resize conductor RPC method https://review.opendev.org/638047

Earlier   Later