| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-11 | |||
| 16:24:49 | sean-k-mooney | am i will after my next 1:1 in 5 mins | |
| 16:24:59 | sean-k-mooney | dansmith: ah ok | |
| 16:26:07 | sean-k-mooney | oh this is for cross cell resize | |
| 16:27:57 | sean-k-mooney | oh its related to the downcall to the compute. hum ya thats tricky | |
| 16:28:47 | sean-k-mooney | well maybe "down call" is not right but the thing we were talking to matt about last week | |
| 19:12:49 | efried | jroll: progress: using ephemeral="yes" nothing shows up on the disk. This means we'll have to define & set the secret on the fly once per guest per service-process-instance, which seems reasonable. | |
| 19:13:45 | efried | jroll: Next sticky design point: bootstrapping the secret UUID. | |
| 19:14:17 | efried | We don't want it to be in the flavor, because then you need a new flavor per secret. | |
| 19:15:52 | efried | I think we can do it this way: Create it with a random secret in the key manager. I guess neither the VM user nor the operator needs to know the secret value; they just have to be able to access it from the keymgr. | |
| 19:16:34 | efried | So we just have to figure out a way to associate the secret UUID with the instance. | |
| 19:16:45 | efried | We could use the instance UUID, but that seems fragile. | |
| 19:17:21 | efried | otherwise I suppose we need to use a new field in the instance. Which makes me a little bit sad, but it's not the end of the world. | |
| 19:17:35 | efried | dansmith: do you have any other suggestions? | |
| 19:18:10 | efried | TL;DR: I'm going to generate a UUID when I create the instance, and need to be able to associate that UUID with the instance for the life of the instance. | |
| 19:18:31 | dansmith | efried: system_metadata ? | |
| 19:18:51 | efried | is that a place I can stuff arbitrary key=value without a schema change? | |
| 19:18:57 | dansmith | efried: yup | |
| 19:18:58 | efried | sounds perfect :) | |
| 19:19:00 | efried | thanks. | |
| 19:19:56 | efried | okay, I think I have enough answers that I can take a break from PoCing and fill in a bunch of the open questions on the spec. (<== TxGirlGeek FYI) | |
| 19:21:53 | sean-k-mooney | efried: you could just use 1 the instance uuid or 1 a uuid5 based on the instance uuid as a seed | |
| 19:22:54 | efried | anything derived from the instance UUID seems brittle, because other things might assume they can do the same. | |
| 19:23:14 | efried | A separate random uuid is safest | |
| 19:23:16 | sean-k-mooney | uuid5 takes a seed uuid + a string | |
| 19:23:27 | sean-k-mooney | so the seed uuid would be the instance uuid | |
| 19:23:28 | efried | oh, that could work. | |
| 19:23:32 | sean-k-mooney | that defines a namespace | |
| 19:23:40 | sean-k-mooney | and then you can generate uuids form that | |
| 19:23:42 | efried | yeah, the string could be "emulated tpm secret" or something unique. | |
| 19:23:50 | sean-k-mooney | ya | |
| 19:24:19 | sean-k-mooney | https://docs.python.org/2/library/uuid.html#uuid.uuid5 | |
| 19:26:46 | dansmith | efried: definitely prefer generation + storing in sysmeta | |
| 19:26:57 | efried | okay | |
| 19:27:29 | sean-k-mooney | yeah you can do both | |
| 19:31:49 | efried | wow cool https://docs.openstack.org/api-ref/key-manager/ | |
| 19:32:20 | dansmith | efried: it's for managing secrets..including the definition of its api | |
| 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 | |