| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-11 | |||
| 19:32:26 | efried | hahahaha | |
| 19:32:49 | mriedem | heh, thought that was fixed awhile ago | |
| 19:32:56 | mriedem | this page last updated: 2018-10-18 16:43:23 | |
| 19:33:30 | mriedem | https://docs.openstack.org/barbican/latest/api/ | |
| 19:33:31 | sean-k-mooney | dont you use castalain or something rather then barbican directly form within nova? | |
| 19:33:40 | mriedem | ^ is where https://docs.openstack.org/api-quick-start/ takes you | |
| 19:34:03 | mriedem | castallan is the interface, barbican is a backend implementation | |
| 19:34:11 | sean-k-mooney | ya that works https://docs.openstack.org/barbican/latest/api/reference/secrets.html | |
| 19:34:24 | NostawRm | I'm exploring the possibility of adding another image backend for Glance and Nova before working out a blueprint, spec, etc. Adding a driver to glance seemed straight forward, but the way nova does image backends doesn't seem as if its intended to add more backends since its all in one file. Is this the case and using boot from volume is intended or am I making bad assumptions? | |
| 19:35:02 | mriedem | NostawRm: if it's adding a backend that is already supported by cinder than it's likely not going to get much traction | |
| 19:35:30 | mriedem | EMC ScaleIO was the last to try and fail at that | |
| 19:35:31 | sean-k-mooney | NostawRm: it also depends on your usecase. | |
| 19:36:41 | sean-k-mooney | e.g. what advantage would it bring to have a new iamge backend over cinder/bfv | |
| 19:37:39 | dansmith | NostawRm: are you the one that asked on the ML earlier today? | |
| 19:38:17 | NostawRm | that's a shame, but it makes. When using Ceph/RBD, we used it with ephemeral storage, but StorPool only has volumes, so having to boot from volume. Keep doing work arounds and was looking at attacking it from this angle instead | |
| 19:38:32 | NostawRm | Right now, its because you can't rescue an instance booted from volume | |
| 19:38:38 | NostawRm | dansmith, nah, wasn't me | |
| 19:38:50 | mriedem | so fix rescue to work with volume-backed servers instead... | |
| 19:38:54 | mriedem | like rebuilding volume-backed servers | |
| 19:38:54 | dansmith | NostawRm: ack, well, you might go look at my response then :) | |
| 19:38:55 | mriedem | etc | |
| 19:39:03 | NostawRm | But if that's the case, I suppose it is just what it is | |
| 19:39:09 | dansmith | mriedem: heh, exactly what I said in my response | |
| 19:39:21 | mriedem | we are sympatico | |
| 19:39:33 | sean-k-mooney | were is the spec for detaching a root volume | |
| 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. | |