| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-11 | |||
| 19:39:54 | dansmith | NostawRm: http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010678.html | |
| 19:40:14 | sean-k-mooney | resucing a boot form volume instance is a similar usecase | |
| 19:40:35 | dansmith | sean-k-mooney: not really, rescue wouldn't require a detach | |
| 19:40:38 | dansmith | just a boot order change | |
| 19:40:46 | sean-k-mooney | ya thats true | |
| 19:40:53 | NostawRm | That's hilarious | |
| 19:40:58 | NostawRm | that its also StorPool | |
| 19:41:01 | sean-k-mooney | but if you can detact it you can detach and add it to another instance | |
| 19:41:09 | dansmith | sean-k-mooney: that's not what rescue is | |
| 19:41:24 | sean-k-mooney | i know rescue is booting and existing instance in place so you can fix it | |
| 19:41:42 | TxGirlGeek | efried got it :) | |
| 19:41:44 | sean-k-mooney | but you can detach attach fix detach retatach to original instnace | |
| 19:41:50 | sean-k-mooney | *you could | |
| 19:42:13 | sean-k-mooney | any fixing resucre for bfv is userful too | |
| 19:47:39 | sean-k-mooney | by the way anyone know if the topic of a generic cinder image backend come up again at the PTG. bfv is not quite the same thing but if we were to add another imgage backend that would be my goto approach | |
| 19:47:59 | sean-k-mooney | fixing bfv to do what you want feels like a lot less work however | |
| 19:49:45 | mriedem | dansmith: didn't lee's old spec cover volume-backed rescue? https://review.opendev.org/#/c/651151/ | |
| 19:50:18 | dansmith | mriedem: I dunno, it'd be an important part of it though | |
| 19:51:57 | jroll | efried: that all sounds good, although I don't even think the VM user or operator needs to be able to access the key in the secret manager. but yeah +1 to all the rest | |
| 19:52:54 | NostawRm | So, I'm fairly certain that the Mailing list thread was created because of me bothering StorPool. I was looking at possible solutions to propose to them, seems like they were already on it too :) | |
| 19:52:57 | sean-k-mooney | jroll: i think the operator definetly shound not be able to | |
| 19:53:08 | sean-k-mooney | the user maybe but proably not | |
| 19:53:12 | jroll | yep | |
| 19:53:37 | sean-k-mooney | the user might have to be able to acess it if we use there auth token to manage it | |
| 19:53:48 | efried | jroll: I don't know what ability is conferred upon the "operator", by virtue of being the same user as is booting the instance | |
| 19:54:22 | efried | n-cpu is going to access the key manager service and be able to create & retrieve the passphrase based on being credentialed as the operator, no? | |
| 19:54:34 | sean-k-mooney | no | |
| 19:54:40 | efried | so couldn't the operator, using the same creds, simply go retrieve same? | |
| 19:54:41 | efried | oh? | |
| 19:54:54 | dansmith | generally the user's creds would be passed to barbican right? | |
| 19:54:56 | sean-k-mooney | efried: nova compute should be useing the autoken form the boot request | |
| 19:55:08 | efried | is that not what I said? | |
| 19:55:12 | dansmith | which means you can't start the instance in isolation, but when the user does a start, you can auth and get the deets | |
| 19:55:39 | sean-k-mooney | efried: operaor generaly refers to the cloud admin | |
| 19:55:41 | dansmith | efried: you said "credentialed as the operator" | |
| 19:55:52 | efried | I thought "operator" in this context was "guy creating instance". | |
| 19:55:56 | efried | as opposed to "admin". | |
| 19:55:57 | dansmith | hah | |
| 19:55:59 | dansmith | no | |
| 19:56:07 | efried | did I want "user"? | |
| 19:56:10 | dansmith | yes | |
| 19:56:15 | efried | sigh, okay. | |
| 19:56:16 | efried | So | |
| 19:56:17 | sean-k-mooney | user or tenant | |
| 19:56:26 | efried | "user" is the one with access to the secret | |
| 19:56:27 | mriedem | NostawRm: fwiw i replied to the thread and linked in a bunch of pre-existing design work on several volume-backed server feature gaps in the api if you're so inclined to push your vendor to fund a developer to work on those again | |
| 19:56:38 | sean-k-mooney | yes ideally | |
| 19:56:43 | efried | doesn't this have implications for certain lifecycle operations? | |
| 19:56:49 | sean-k-mooney | yes | |
| 19:56:51 | efried | ...that are done by admins? | |
| 19:56:54 | dansmith | efried: see what I said above about restart | |
| 19:57:09 | sean-k-mooney | efried: this is already the case for encyped instances | |
| 19:57:19 | dansmith | right | |
| 19:57:38 | efried | what operations are done by admins? | |
| 19:57:47 | dansmith | live migrate, restarting a compute host | |
| 19:58:10 | sean-k-mooney | live migrate might be ok | |
| 19:58:11 | dansmith | (and cold migrate of course | |
| 19:58:25 | efried | *can* live migrate be done by the user? | |
| 19:58:27 | sean-k-mooney | assuming libvirt woudl transfer the key | |
| 19:58:34 | dansmith | efried: if granted, but not usually | |
| 19:58:37 | dansmith | sean-k-mooney: yeah, fair | |
| 19:58:41 | sean-k-mooney | efried: not unless you change the policy.json | |
| 19:58:54 | dansmith | but cold migrate wouldn't work | |
| 19:59:09 | efried | "libvirt would transfer the key" -- meaning the secret I loaded into the libvirtd on host1 would transfer over to the libvirtd on host2? | |
| 19:59:13 | sean-k-mooney | well cold migrate would result in the vm being ofline? | |
| 19:59:26 | sean-k-mooney | we would not be able to start it | |
| 19:59:34 | sean-k-mooney | a user could do a resize | |
| 19:59:38 | sean-k-mooney | that should work | |
| 19:59:54 | dansmith | sean-k-mooney: usually it is done on a running instance | |
| 19:59:55 | dansmith | yeah, user-initiated resize should be doable | |
| 20:00:13 | dansmith | cold migrate would need to either fail early, or else it would result in an offlined vm that the admin can't restart | |
| 20:00:21 | dansmith | so not useful for maintenance without significant disruption | |
| 20:00:31 | NostawRm | efried: I really appreciate that. I also don't mind putting in the work to contribute, I just like to check here to make sure the contributions wouldn't be immediately shot down if I can't find it being discussed anywhere else. Thanks! | |
| 20:00:37 | dansmith | no way around that, but ideally it would refuse to move it so they don't accidentally break instances | |
| 20:00:57 | efried | I think the secret stays loaded up in libvirtd as long as that process is running, so admin could do pretty much anything that keeps the instance on the same host; as long as they don't restart libvirtd the instance will come back up. | |
| 20:01:23 | efried | I guess I'll have to test the secret-goes-with-live-migrate theory. | |
| 20:01:49 | sean-k-mooney | efried: ya maybe that would be correct | |
| 20:01:59 | dansmith | efried: hopefully libvirt won't show you te secret right? | |
| 20:01:59 | sean-k-mooney | however hard reboot deletes the domain | |
| 20:02:06 | sean-k-mooney | and recreates it | |
| 20:02:13 | efried | dansmith: it won't, as long as private='yes'. | |
| 20:02:19 | sean-k-mooney | so that might clear the secret | |
| 20:02:29 | efried | sean-k-mooney: I'm saying specifically that doesn't matter. | |
| 20:02:35 | dansmith | efried: yeah, so you can't use that to do an unauthorized cold migration, if that's what you're implying | |
| 20:02:55 | efried | dansmith: understood for cold, but still wondering about live. | |
| 20:03:15 | dansmith | efried: live should work I would think | |
| 20:03:28 | dansmith | efried: if not, graceful fail, otherwise you'd migrate into an unrunnable state | |
| 20:05:02 | efried | setting up the secret and creating the instance are totally different things, from what I understand. I wouldn't expect libvirt to transfer the actual secret to the destination. However, if it's transferring the "state" of the instance, which includes an already-unencrypted vtpm, that might work. But then the VM on the target is kind of in a different condition than it was on the source, in that the secret is not loaded. | |
| 20:05:32 | dansmith | efried: oh, well in that case maybe worth more thinking, | |
| 20:05:33 | efried | so like the reboot-recreate-xml scenario would *not* work in that case. | |
| 20:06:02 | sean-k-mooney | i can ask danpb tomorow when he is online if he knows what is expected to happen | |
| 20:06:03 | dansmith | efried: but since the instances can't be restarted without the user's creds anyway, even if it migrates and can't reboot | |
| 20:06:05 | dansmith | that would be the same | |
| 20:06:12 | sean-k-mooney | but testing might give you an answer quiciker | |
| 20:07:26 | sean-k-mooney | what is the state of migrations for instnace with encyption today | |
| 20:07:36 | efried | dansmith: well, what I was saying is, once the secret is loaded up in libvirtd, anybody would be able to restart, without user's creds. | |
| 20:07:44 | sean-k-mooney | the vtpm would likely have the same constraints | |
| 20:08:06 | dansmith | efried: ...and break the ability to restart the instance in place you mean right? | |
| 20:08:08 | efried | unless we do a step to undefine the secret when rebooting or something. | |
| 20:08:51 | sean-k-mooney | efried: well we proably shoudl do that as part of stop | |