Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-11
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
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?

Earlier   Later