| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 19:09:00 | mriedem | it's a small inconsistency cleanup in the api spec so people have said it should be merged into your general cleanup spec, but that's just adding more stuff to your already somewhat large api change | |
| 19:23:29 | mriedem | efried: questions in https://review.opendev.org/#/c/654457/ | |
| 19:23:43 | efried | ... | |
| 19:24:21 | efried | eandersson: ^ | |
| 19:25:12 | mriedem | why not squash those 2 changes together? | |
| 19:27:11 | efried | They're pretty unrelated. | |
| 19:27:47 | efried | one fixes how we do ksa stuff, the other fixes how we construct the ironicclient | |
| 19:29:00 | mriedem | it seems the answer to my question here https://review.opendev.org/#/c/654457/2/nova/virt/ironic/client_wrapper.py@131 though is 'ironicclient will try to sort it out' but needs the region_name passed along as well (if you've got multiple regions and are configuring nova-compute to talk to different ones) | |
| 19:31:08 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Support adding the reason behind a server lock https://review.opendev.org/648662 | |
| 19:31:51 | efried | mriedem: Yes. | |
| 19:32:00 | efried | Though I think that was actually not the case until recently. | |
| 19:32:16 | efried | I think the logic to "figure it out" was broken until https://github.com/openstack/python-ironicclient/commit/c038f1db67e7809513d5535648d15c3590b191d5 ? | |
| 19:33:58 | efried | mriedem: so, do you want these squashed? Am I being silly asserting that they're doing different things? | |
| 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 | aspiers | right | |
| 20:29:34 | artom | Like SEV ;) | |
| 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 | aspiers: Until we polish up that RequestSpec.requested_resources thing: | |
| 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 | ==> to a resources:MEM_ENC_CTX=1 in the same RequestSpec's flavor extra specs | |
| 20:30:16 | efried | but that's okay because that request spec's flavor is *not* persisted to the db. | |
| 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: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 | |