| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-11 | |||
| 16:10:44 | dansmith | cdent: the shortcut is: we do a cast if allow_cross_cell_resize is true, and (in a later patch) that will be true based on your policy | |
| 16:11:03 | dansmith | and that seems bad | |
| 16:11:59 | cdent | so cloud A wouild be cast and B would be call, dependent on policy settings? would it be discoverable in any way? | |
| 16:12:58 | cdent | hmmm. however, is a user ever supposed to that cells exist? | |
| 16:13:35 | cdent | because this isn't preventing or allowing resize, correct? just resize of a particular type? | |
| 16:14:15 | dansmith | cdent: no, it'd be *User* A and user B that see differences, in the same cloud | |
| 16:14:39 | dansmith | cdent: and no, a user would not know they have this ability, nor know why they see different behavior from their peer | |
| 16:15:06 | cdent | hmmm. is there a short explanation for the "why" on controlling by policy? | |
| 16:15:13 | dansmith | cdent: it's literally gating whether or not the scheduler will return all hosts, or only hosts within the current cell, not something the user knows about | |
| 16:15:30 | cdent | (I'm trying to read the code, but there's a lot here) | |
| 16:15:35 | dansmith | cdent: the why is so you can control it per-user, where config would be per-cloud | |
| 16:15:59 | cdent | yes, but _why_ would you control is per user? | |
| 16:16:00 | cdent | s/is/it/ | |
| 16:16:12 | dansmith | cdent: because it | |
| 16:16:24 | dansmith | is more expensive, and/or you may have other reasons, | |
| 16:17:10 | dansmith | it's a little weird that it's a policy knob, but it is that way just so that it can be controlled per user for whatever reason | |
| 16:17:34 | cdent | I can see that people would want that, even though they shouldn't ;) | |
| 16:17:45 | cdent | everybody wants the knobs | |
| 16:18:05 | cdent | okay, I think I have enough info to think about this with some level of legitimacy | |
| 16:18:09 | dansmith | well, that's a different argument I guess, but ... yeah. | |
| 16:18:20 | dansmith | my other argument would be that this is potentially more failure-prone, | |
| 16:18:37 | dansmith | so you may not want to give it to "simple people" or something | |
| 16:18:45 | dansmith | or just let admins do it so they can move things around the cloud | |
| 16:18:58 | dansmith | like the policy knob that lets you direct migrations to a specific host vs. just use the scheduler | |
| 16:19:16 | dansmith | but regardless, that discussion is somewhat separate from the api behavior thing | |
| 16:19:44 | cdent | yeah, just trying to add a bit of definition so I'm not filling in the blanks poorly | |
| 16:19:57 | dansmith | yup | |
| 16:20:23 | dansmith | explaining it to you here makes me feel more like my +0 should be a -1 | |
| 16:21:01 | cdent | what it is doing seems like the right thing, but I agree that it should have a microversion for the reason you state: change in behavior when same code has a different user using it | |
| 16:21:06 | cdent | i'll say as much on the review | |
| 16:21:09 | sean-k-mooney | dansmith: i dont know if you could take extention list approch like neutron | |
| 16:21:23 | sean-k-mooney | dansmith: and have that reterun different values based on policy | |
| 16:21:31 | cdent | what neutron does is terrifying from an api standpoint | |
| 16:21:44 | sean-k-mooney | well at least you can detect it | |
| 16:21:51 | dansmith | cdent: the microversion would have to say "after microversion 2.X, the method could be sync or async so watch your return code" | |
| 16:21:52 | sean-k-mooney | but yes | |
| 16:21:59 | sean-k-mooney | it still feels weird | |
| 16:22:00 | dansmith | cdent: which I thought is one of the reasons we *don't* add a microversion | |
| 16:22:22 | dansmith | sean-k-mooney: we specifically do not version our api via extensions anymore, so I'm not sure why you'd suggest that | |
| 16:22:27 | dansmith | that's the whole point of microversions :) | |
| 16:22:39 | sean-k-mooney | dansmith: neutron uses bot | |
| 16:22:42 | sean-k-mooney | *both | |
| 16:22:52 | sean-k-mooney | on your return code point | |
| 16:23:08 | sean-k-mooney | it woudl be 200 for syc and 202 or 203 for async? | |
| 16:23:30 | dansmith | sean-k-mooney: I said that above | |
| 16:23:58 | sean-k-mooney | would they send the same payload in both cases? | |
| 16:24:23 | dansmith | sean-k-mooney: you might want to read the backscroll and the code/comment I linked above | |
| 16:24:25 | sean-k-mooney | i kind of feel like haveing a flag in the post body would be cleaner | |
| 16:24:28 | dansmith | it'd be good context for the conversation | |
| 16:24:47 | dansmith | sean-k-mooney: because I've said several times that this is not something user knows about or can/would opt into | |
| 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? | |