| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 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 | |
| 11:33:22 | sean-k-mooney | i think its fair to say that if you have very complex resouce and traits request in flavor that opens you up to some upgrade impacts that you woudl otehrwise not be exposed too | |
| 11:33:30 | bauzas | whether we should factorize the forgeries into one piece is debatable | |
| 11:33:50 | sean-k-mooney | perhasp something to consier in the future | |
| 11:34:00 | sean-k-mooney | but i dint think its required right now | |
| 11:34:06 | bauzas | yeah | |
| 11:34:54 | bauzas | also, have we ever tried to sanitize os-traits before ? | |
| 11:35:49 | bauzas | sounds now nearly impossible to me | |
| 11:36:13 | sean-k-mooney | we are not allowed to remove traits form os-traits | |
| 11:36:17 | sean-k-mooney | ever | |
| 11:36:24 | sean-k-mooney | placement does not support that today | |
| 11:36:29 | bauzas | I reached to that conclusion | |
| 11:36:55 | sean-k-mooney | it could be done with some mettadata but basically we need to resver the triat ids in the db | |
| 11:40:23 | bauzas | anyway, I need to deserve time for lunch and writing my own spec | |
| 11:56:33 | opendevreview | Merged openstack/nova-specs master: Add libvirt-dev-alias spec https://review.opendev.org/c/openstack/nova-specs/+/892806 | |
| 12:19:52 | opendevreview | sean mooney proposed openstack/nova master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/nova/+/899753 | |
| 12:22:06 | Continuity | hey all, I have submitted a PR (https://review.opendev.org/c/openstack/nova/+/900252) and I'm struggling to understand and fix the build errors. Mostly around openstack-tox-cover, openstack-tox-py38 and nova-tox-py310-with-sqlalchemy-2x. It seems to be a case of, works fine on my local machine :D | |
| 12:22:12 | Continuity | anyone have any pointers | |
| 12:28:46 | sean-k-mooney | Continuity: the pep8 failures look valid https://zuul.opendev.org/t/openstack/build/914ce175822a4ada8271b3d5ae9d6877/log/job-output.txt#4269-4282 | |
| 12:30:11 | sean-k-mooney | Continuity: we will also need a bug or specless blueprint to proceed with this feature | |
| 12:31:06 | sean-k-mooney | the unit test failrue also look valid https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_3b1/900252/2/check/openstack-tox-py38/3b1dc22/testr_results.html | |
| 12:31:42 | sean-k-mooney | requests.exceptions.MissingSchema: Invalid URL 'POST': No scheme supplied. Perhaps you meant https://POST? | |
| 12:33:19 | Continuity | sean-k-mooney: yeah I agree they look correct, thats the issue, when I run the tox commands locally they pass :S | |
| 12:33:22 | sean-k-mooney | Continuity: the fact you are gettign fewer error in 3.10 vs 3.8 is concerning | |