| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 11:09:06 | bauzas | and operators could be trying to test fancy things by exposing those traits in a flavor | |
| 11:09:37 | stephenfin | zigo: nothing I can do about that, I'm afraid. I've pushed patches for Masakari and repeatedly trumpted the fact that this needs to be addressed in other projects | |
| 11:09:38 | bauzas | I'd rather do an explicit list of traits we allow to specify | |
| 11:09:39 | sean-k-mooney | specific these ones are genrally valid to request https://github.com/openstack/os-traits/tree/master/os_traits/hw/cpu | |
| 11:09:43 | bauzas | sean-k-mooneylike a public API | |
| 11:09:56 | bauzas | we have a stand on the contractual API we support | |
| 11:09:59 | sean-k-mooney | bauzas: we could always enchnae the flavor validtor | |
| 11:10:13 | stephenfin | zigo: Those will break when we uncap SQLAlchemy. They'll have to fix it then 🤷�♂� | |
| 11:10:13 | stephenfin | zigo: Those will break when we uncap SQLAlchemy. They'll have to fix it then 🤷♂️ | |
| 11:10:35 | opendevreview | Steven Relf proposed openstack/nova master: Adding basic auth to dynamic vendordata api calls https://review.opendev.org/c/openstack/nova/+/900252 | |
| 11:10:44 | bauzas | sean-k-mooney: I don't know what to do, that's the point | |
| 11:11:02 | bauzas | what's easier is when you have a prefilter or the requestspec translator | |
| 11:11:17 | bauzas | then we can say 'sorry, no, not intended to be used this way' | |
| 11:11:27 | sean-k-mooney | yep so when adding new extraspecs/image proeprts and a trait | |
| 11:11:32 | zigo | stephenfin: Thanks for letting me know, I'll see if we can invest time in at least cloudkitty that we use in production. | |
| 11:11:35 | sean-k-mooney | i think we shoudl alwasy prvied the prefilter/translator | |
| 11:11:54 | bauzas | sean-k-mooney: sounds a direction | |
| 11:12:19 | sean-k-mooney | and we could enhance the flavor validation api to also reject the use of the "resrved traits" in the future | |
| 11:12:41 | sean-k-mooney | bauzas: https://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/traits.py | |
| 11:12:45 | bauzas | I mean, for the short future, we need to agree between us as cores | |
| 11:13:15 | sean-k-mooney | yep | |
| 11:13:33 | sean-k-mooney | we shoudl likely update the contibutors guide or add a new refence doc | |
| 11:13:34 | bauzas | I'll capture that in a doc patch | |
| 11:13:42 | sean-k-mooney | i.e. how to design with triats and resouce classes | |
| 11:13:44 | bauzas | that's a start | |
| 11:14:14 | sean-k-mooney | i woudl add a new doc in https://github.com/openstack/nova/tree/master/doc/source/reference | |
| 11:14:27 | sean-k-mooney | or here https://github.com/openstack/nova/tree/master/doc/source/contributor | |
| 11:14:58 | sean-k-mooney | bauzas: on a related note i really dont like usign resouces: in genreal in the flavor either | |
| 11:15:00 | bauzas | yeah the latter was the one I thought | |
| 11:15:10 | sean-k-mooney | i kind of whish we had vgpu: instead | |
| 11:15:23 | bauzas | sean-k-mooney: I don't disagree | |
| 11:15:35 | sean-k-mooney | the main reason i say this is i dont like the way grouping works | |
| 11:15:46 | bauzas | particularly if a VGPU resource could be a mdev or a VF in the next future | |
| 11:15:51 | sean-k-mooney | i think that is leaking too much about how we modle things in placment | |
| 11:15:57 | bauzas | yeah | |
| 11:16:06 | bauzas | and it creates us some binding | |
| 11:16:10 | sean-k-mooney | ya so i woudl prefer vgpu: to work kind fo liek the pci alias | |
| 11:16:27 | bauzas | does it sound another action item for vgpus ? | |
| 11:16:33 | sean-k-mooney | so we have a layer of indirection | |
| 11:16:43 | bauzas | man, I really should invent the cloning machine first | |
| 11:16:48 | sean-k-mooney | am im not sure based on the lifespan of vgpus | |
| 11:16:59 | sean-k-mooney | but doign this as mdev: i could get behind | |
| 11:17:35 | sean-k-mooney | im expecgint that we will just use the pci_alias goign forward for sriov vgpus implemenations | |
| 11:17:55 | bauzas | actually, having mdevs: flavor resources sounds better for operators if we start support vfio-pci for GPUs | |
| 11:17:57 | sean-k-mooney | having this indrection for mdevs in general i thikn would be nice but not required | |
| 11:18:03 | bauzas | yeah | |
| 11:18:34 | sean-k-mooney | so effectivly we woudl extend the devices section or one of the dynmic section with an alias option | |
| 11:18:37 | bauzas | when I read my code last week, I thought I spoiled too many vgpu acronyms in the code while this can be mdev agnostic | |
| 11:18:49 | stephenfin | zigo: nw. The topic bauzas mentioned will bring up most patches, and I suspect there are solutions to most potential upgrade issues there | |
| 11:19:00 | stephenfin | topic:sqlalchemy-20 | |
| 11:19:10 | dvo-plv | sean-k-mooney, bauzas I a little bit confused after this conversation. you talked regarding prefilter, as far as I understand about that https://review.opendev.org/c/openstack/nova/+/876075/25/nova/scheduler/request_filter.py#275 | |
| 11:19:28 | dvo-plv | But i did not get if i need to change approach | |
| 11:19:31 | zigo | stephenfin: Yeah, I managed to upload Heat 21.0.0 with all the 12 patches already ! :) | |
| 11:19:37 | zigo | Currently working on Glance. | |
| 11:20:03 | bauzas | dvo-plv: no, you don't need to change the approach if sean-k-mooney and some other core agree on your updated spec | |
| 11:20:21 | sean-k-mooney | dvo-plv: that is fine in my view, no change required | |
| 11:20:32 | sean-k-mooney | dvo-plv: we just have 2 places where you can do this | |
| 11:20:44 | sean-k-mooney | dvo-plv: either as a trival prefilter there | |
| 11:20:50 | bauzas | based on the discussion I just had with sean at the last min, I could even approve the spec now, provided we draw the line | |
| 11:21:03 | sean-k-mooney | or in the schduler utils | |
| 11:21:51 | sean-k-mooney | dvo-plv: like this https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L288-L304 | |
| 11:22:13 | sean-k-mooney | dvo-plv: it has the same effect | |
| 11:22:37 | sean-k-mooney | dvo-plv: the only reason to prefer a prefiler over a translate function like that is if you want ot make it configurable | |
| 11:23:02 | bauzas | right | |
| 11:23:06 | sean-k-mooney | dvo-plv: in your case we dont need or want it to be configurable (its not in your patch) | |
| 11:23:08 | bauzas | you can opt-out | |
| 11:23:23 | sean-k-mooney | but we have mandaotry pre-filters too | |
| 11:23:28 | bauzas | (or opt-in, depending on the default value :) ) | |
| 11:23:29 | sean-k-mooney | so either approch works | |
| 11:23:56 | bauzas | actually | |
| 11:24:19 | bauzas | this sounds terrible for interop if we make those image properties be config-driven, right? | |
| 11:24:20 | sean-k-mooney | dvo-plv: i think we get slightly better logging in general with the prefilter but its basically the same | |
| 11:24:34 | sean-k-mooney | bauzas: it woudl be but its not | |
| 11:24:43 | sean-k-mooney | triat help with interup | |
| 11:24:57 | sean-k-mooney | but only if you have access to placement | |
| 11:25:01 | bauzas | well, if you disable the prefilter, then your property is useless, right? | |
| 11:25:16 | sean-k-mooney | bauzas: the prefilter cant be disabeld | |
| 11:25:36 | bauzas | in the current code, yeah | |
| 11:25:45 | bauzas | but in general, we have prefilters that are config-driven | |
| 11:26:02 | sean-k-mooney | yes but those are genrelaly not related to extra specs | |
| 11:26:18 | bauzas | sure, but that's again errorprone | |
| 11:26:27 | dvo-plv | okay, great that you are on the same page now and all left the friends :) So, I will resolve comments asap, than kyou again | |
| 11:26:48 | sean-k-mooney | bauzas: over time i would expect use to make some prefilters that you can currently opt out of mandatory | |
| 11:26:53 | bauzas | some day we may want to have some configurable prefilter that would do property translation | |
| 11:27:03 | sean-k-mooney | i recently did that for the az prefilter when i remvoed teh az filter | |
| 11:27:51 | sean-k-mooney | i could see use makign the require_image_type_support or transform_image_metadata required at some point | |
| 11:28:21 | sean-k-mooney | bauzas: actully looking at the code more are required then optional today | |
| 11:28:50 | bauzas | yeah fortunately | |
| 11:29:05 | sean-k-mooney | bauzas: we have for image properties already | |
| 11:29:23 | sean-k-mooney | i wrote a genric one to work with all image properties that have corresponding triats | |
| 11:29:36 | sean-k-mooney | we just need to extend that as it make sense | |
| 11:29:58 | sean-k-mooney | i didnt do that for flavors mainly because there are less extra spec that map to triat | |
| 11:30:11 | sean-k-mooney | but reflectign on that it might make sense too revisit that | |
| 11:30:35 | sean-k-mooney | there is likely some consoliation i coudl to with low amoutn of work | |
| 11:31:00 | sean-k-mooney | do you think that woudl be valuable. i just havent felt the effort was worth it previously | |
| 11:31:39 | bauzas | that's a very good question | |
| 11:31:55 | sean-k-mooney | prefilters/translaotr tend to be a single short funciton that is easy to test in isolation | |
| 11:32:13 | sean-k-mooney | combining them loose some of that simplicty depending on how you approch it | |
| 11:32:32 | bauzas | I'm still afraid by the imagination of our lovely operators and I want us to draw a solid yellow line in terms of support, since I don't wanna buy some trait forever | |
| 11:33:07 | bauzas | so, any forgery hiding traits sounds preferable | |