| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 19:37:05 | mriedem | well, it looks like it might be better to keep them separate because of how ironicclient handles the kwargs in older releases, it looks like region_name was only since Ifc7b45d047c8882a41021e1604b74d17eac2e6e8 in rocky and before that it was os_region_name | |
| 19:37:15 | mriedem | so backports to queens for eandersson's change could be a bit trickier | |
| 19:37:21 | mriedem | especially since we don't have integration testing for this stuff | |
| 19:41:24 | mriedem | ok +2 on the bottom and +W on the top | |
| 19:41:39 | efried | thanks mriedem. Any idea who else should look at the bottom one? | |
| 19:41:52 | mriedem | https://review.opendev.org/#/q/topic:bug/1825583+(status:open+OR+status:merged) | |
| 19:41:54 | mriedem | cleans that up | |
| 19:41:57 | mriedem | you guys and your silly tp's | |
| 19:42:00 | mriedem | *tb's | |
| 19:42:09 | mriedem | efried: ummm, melwitt? | |
| 19:42:40 | artom | Wheel of cortune | |
| 19:42:46 | efried | nice | |
| 19:43:18 | artom | That's basically the extent of my contribution here. Puns. | |
| 19:49:58 | eandersson | Not backporting mine beyond Rocky is fine, as the main patch will fix most cases. | |
| 19:50:13 | eandersson | And endpoint_override is a valid work around. | |
| 20:00:11 | mriedem | and you're on rocky so you don't have to care about queens :) | |
| 20:13:11 | mriedem | it's sad that something as simple as "pass az to unshelve" https://review.opendev.org/#/c/624689/ is this complicated | |
| 20:16:15 | mriedem | sorrison: i think this old bug https://bugs.launchpad.net/nova/+bug/1453629 has been fixed since pike due to https://review.opendev.org/#/c/446053/ - are you on pike or later and can confirm? | |
| 20:16:20 | openstack | Launchpad bug 1453629 in OpenStack Compute (nova) "Creating neutron ports uses incorrect instance availability zone" [Low,Confirmed] | |
| 20:18:52 | colby_ | Hey All. Is there any way to have shelved_offloaded instances not count toward cpu hours/ram hour usage? | |
| 20:19:56 | aspiers | efried: if resources:foo=1 doesn't currently work with image properties, I'm unsure how it would work when translating another image property gimme_foo=true into it within request_filter.py | |
| 20:21:20 | aspiers | efried: wouldn't we have to add support to ResourceRequest.from_image_props() at least? | |
| 20:22:21 | sean-k-mooney | aspiers: you are not allowed to request resoruce from an image | |
| 20:23:06 | sean-k-mooney | and i dont think that should be part of teh SEV spec if we intoduce it | |
| 20:24:18 | aspiers | sean-k-mooney: is the term "resource" overloaded here? | |
| 20:24:53 | sean-k-mooney | i assume resouce:foo was a placment resouce class request | |
| 20:24:55 | aspiers | sean-k-mooney: by the way it's named, ResourceRequest.from_image_props() considers an image property requesting a trait as a resource request | |
| 20:25:02 | sean-k-mooney | that is not allowed in an image | |
| 20:25:37 | aspiers | so in that naming, a "resource" can also refer to something wider which can include traits, not just something from a resource class | |
| 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/ | |