| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 20:25:47 | sean-k-mooney | is that in the nova code? | |
| 20:25:51 | aspiers | yes | |
| 20:26:00 | aspiers | nova/scheduler/utils.py | |
| 20:26:07 | aspiers | ResourceRequest.from_image_props() | |
| 20:26:29 | aspiers | currently it only supports required traits | |
| 20:26:37 | sean-k-mooney | that jus tgets the traits | |
| 20:26:49 | aspiers | and you seem to be saying that it shouldn't support required resource classes | |
| 20:26:51 | sean-k-mooney | it does not extrage resouces | |
| 20:26:58 | sean-k-mooney | *extract | |
| 20:27:06 | sean-k-mooney | correct it should not | |
| 20:27:08 | aspiers | why is that not allowed? | |
| 20:27:34 | sean-k-mooney | because i can very eassilay do a denical of serivce attack | |
| 20:27:35 | aspiers | I got the impression from other conversations with efried that we could do this | |
| 20:27:49 | sean-k-mooney | or get access to hardware im not billed for | |
| 20:27:53 | aspiers | how? | |
| 20:28:00 | sean-k-mooney | user can upload images | |
| 20:28:05 | aspiers | oh I see | |
| 20:28:20 | sean-k-mooney | if they can request any resouce then can ask for a vgpu for example but select the smalest flavor | |
| 20:28:37 | aspiers | how is that different with traits? | |
| 20:28:58 | sean-k-mooney | traits do not change teh abount of resocue you are requesting | |
| 20:29:17 | sean-k-mooney | then just filter the posible resouce providers that the resouce can come form | |
| 20:29:25 | artom | I think aspiers's point is that a public cloud might want to bill for a qualitative thing | |
| 20:29:34 | artom | Like SEV ;) | |
| 20:29:34 | aspiers | right | |
| 20:29:35 | sean-k-mooney | artom: they might | |
| 20:29:42 | sean-k-mooney | but its not a security risk | |
| 20:30:16 | efried | So the placement-ese resource request exists as a flavor extra spec when it's used to create the placement GET /a_c request, but only then. | |
| 20:30:16 | efried | but that's okay because that request spec's flavor is *not* persisted to the db. | |
| 20:30:16 | efried | ==> to a resources:MEM_ENC_CTX=1 in the same RequestSpec's flavor extra specs | |
| 20:30:16 | efried | You're translating encrypt_my_memory=true, which you glean from either the image or the flavor extra specs, gleaned from the RequestSpec | |
| 20:30:16 | efried | aspiers: Until we polish up that RequestSpec.requested_resources thing: | |
| 20:30:32 | artom | Well, no, but it's still a financial risk if users can give themselves qualitative things through image props | |
| 20:31:08 | sean-k-mooney | artom: if you care you can use glances upload filetre to prevent it or not allow user to set metadta on an image | |
| 20:31:16 | artom | True | |
| 20:31:20 | aspiers | efried: ohhh I see | |
| 20:31:26 | efried | technically you're requesting resource from an image property. But not explicitly with placement-y resources keys. | |
| 20:31:34 | sean-k-mooney | but the point is we deliberly choose not to allow resocue request wehn we enabeld tratis | |
| 20:34:09 | mriedem | colby_: there is no support for that but it's come up several times | |
| 20:34:51 | mriedem | colby_: tbc, do you mean not count in the os-simple-tenant-usage API? | |
| 20:35:01 | mriedem | or not count toward quota? | |
| 20:35:19 | aspiers | efried, sean-k-mooney: can we quickly bikeshed the name for the resource class? e.g. MEM_ENC_CTX vs. MEMORY_ENCRYPTED_CONTEXT etc. Do we even need the _CONTEXT suffix? I can't see any precedent for it | |
| 20:35:59 | sean-k-mooney | i think we need the sufics otherwise its not a noun | |
| 20:36:17 | aspiers | it could be ENCRYPTED_MEMORY | |
| 20:36:18 | efried | aspiers: The suffix is traditionally units. A sev context thingy is kinda unitless, so not sure that applies. | |
| 20:36:48 | sean-k-mooney | thats still technically an ajitive | |
| 20:36:52 | efried | ENCRYPTED_MEMORY makes it sound like a trait. | |
| 20:36:59 | sean-k-mooney | yep | |
| 20:37:10 | aspiers | encrypted is an adjective, memory is a noun | |
| 20:37:22 | sean-k-mooney | not really | |
| 20:37:27 | aspiers | really ;-) | |
| 20:38:09 | aspiers | well, for sure memory is a noun | |
| 20:38:16 | aspiers | I think encrypted is a gerund or maybe a gerundive | |
| 20:38:30 | aspiers | and they function as an adjective at least | |
| 20:38:39 | sean-k-mooney | my other issue with encryped_memory is the units it impiles | |
| 20:38:52 | aspiers | agreed | |
| 20:39:01 | sean-k-mooney | we have memory_mb | |
| 20:39:15 | sean-k-mooney | i woudl expect encrpted_memory to also be in mb | |
| 20:39:28 | aspiers | yup, so that doesn't work | |
| 20:39:30 | sean-k-mooney | encrypted_memory_context | |
| 20:39:46 | sean-k-mooney | i woudl expect ot have idfferent units | |
| 20:40:12 | aspiers | memory_encrypted_guests? | |
| 20:40:27 | aspiers | the unit is one guest | |
| 20:40:32 | sean-k-mooney | no the units are stil wrong | |
| 20:41:10 | aspiers | wrong how? | |
| 20:41:12 | sean-k-mooney | if i have a multi numa node guest how many sev contextes do i need 1 or more then 1 | |
| 20:41:20 | aspiers | 1 | |
| 20:41:35 | aspiers | AFAIK | |
| 20:42:07 | sean-k-mooney | the bit that buggs me with memory_encrypted_guests is if we port the num_instance_filter to placement in the future | |
| 20:42:18 | sean-k-mooney | we could have an inventory of guests/isntance | |
| 20:42:23 | sean-k-mooney | ont he hypervior | |
| 20:42:59 | aspiers | why is that an issue/ | |
| 20:43:01 | sean-k-mooney | so it coudl be a bit strange to consome 1 allocation of memory_encrypted_guest and 1 allocation of insntace | |
| 20:43:50 | aspiers | doesn't seem particularly strange to me :) | |
| 20:44:13 | aspiers | they are different counts | |
| 20:44:15 | sean-k-mooney | why not just SEV_CONTEXT | |
| 20:44:35 | aspiers | because efried doesn't want a vendor-specific name | |
| 20:44:43 | sean-k-mooney | i had tought efried last stamet was to go with a speficig vendero one first | |
| 20:44:46 | aspiers | as discussed earlier | |
| 20:44:51 | aspiers | no, the opposite | |
| 20:44:55 | sean-k-mooney | efried: ? | |
| 20:45:02 | aspiers | I proposed SEV_CONTEXT and he argued for the opposite | |
| 20:45:09 | aspiers | you can see in the latest spec comments | |
| 20:45:28 | aspiers | https://review.opendev.org/#/c/641994/11/specs/train/approved/amd-sev-libvirt-support.rst@541 | |
| 20:45:35 | sean-k-mooney | we went back and fort on that a few times so i was nto sure what the latest was | |
| 20:46:12 | aspiers | there are pros and cons both ways | |
| 20:46:14 | aspiers | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-04-23.log.html#t2019-04-23T18:03:32 | |
| 20:48:09 | sean-k-mooney | well unless its partiaclarly egregious im not going to -1 over the resocue class name | |
| 20:48:48 | aspiers | OK thanks but would still be nice to pick a good name ;-) | |
| 20:49:07 | aspiers | I was just wondering where the _CONTEXT idea came from | |
| 20:49:09 | sean-k-mooney | i take it you dislike the presence of context | |
| 20:49:16 | sean-k-mooney | proably me | |
| 20:49:25 | aspiers | only slightly, just feels a bit vague | |
| 20:49:47 | sean-k-mooney | well for me i thing of security context in many forms | |
| 20:49:51 | aspiers | but I haven't really come up with anything more precise except _GUEST | |
| 20:50:27 | sean-k-mooney | like an ipsec context | |
| 20:50:27 | aspiers | it would be good to find something which conveys the "1 per guest" notion | |
| 20:50:38 | aspiers | like _SLOTS | |
| 20:51:01 | sean-k-mooney | slot have a more generic meaning to me | |
| 20:51:01 | aspiers | not sure if slots has other meanings in nova already? | |
| 20:51:10 | sean-k-mooney | but kindof | |