Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-11
16:09:40 dansmith cdent: seems like it to me as well
16:10:09 cdent does this apply to something you're looking at (I just got back from being away, so not in context)
16:10:09 dansmith cdent: might be more than you want to digest at the moment, but this is the reference: https://review.opendev.org/#/c/635684/53/nova/compute/api.py@3852
16:10:14 cdent jinx
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

Earlier   Later