| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 10:56:14 | dvo-plv | sure | |
| 10:56:35 | dvo-plv | it sounds critical:) | |
| 10:57:01 | zigo | stephenfin: There are many more services that fail with SQLA 2.x, that haven't been addressed: https://qa.debian.org/excuses.php?experimental=1&package=sqlalchemy | |
| 10:57:01 | zigo | Namely, cloudkitty, trove, ironic-inspector, masakari, sahara, senlin, vitrage, zaqar ... | |
| 10:57:19 | bauzas | your spec will allow operators to not care about mixing hypervisors, which is good, it just doesn't solve our general problem on libvirt knobs we wanna handle | |
| 10:57:45 | bauzas | sean-k-mooney: see, I'm not that dark | |
| 10:58:30 | sean-k-mooney | bauzas: by the way i think we can do a better job on the adress size spec. i -1 with a request to supprot it in image properties adn enchanment to automatically use triats and enchnce the image propperties filter | |
| 10:59:07 | sean-k-mooney | its a minimal expantionin the scope but will basically make it work out of the box for most peopel | |
| 10:59:48 | bauzas | ack, I'll review that one | |
| 11:00:16 | bauzas | tbh, it was a straight reproposal without much additions, I didn't put my brain on it like I did for some other spec :) | |
| 11:00:33 | sean-k-mooney | ya im not sure why i didnt raise these point last cycle | |
| 11:00:38 | bauzas | sean-k-mooney: I also reconsidered the debt we put on ourselves by adding traits | |
| 11:00:41 | sean-k-mooney | which i said in the spec review | |
| 11:01:15 | bauzas | since traits aren't allocations, we can remove compute traits whenever we want, provided we support N-1 or 2 computes | |
| 11:01:30 | bauzas | without need of a reshape | |
| 11:01:36 | sean-k-mooney | you mean requesting and or reporting them? | |
| 11:01:40 | bauzas | both | |
| 11:01:45 | sean-k-mooney | in general we shoudl never remove standard traits | |
| 11:01:58 | sean-k-mooney | as it can break flavors or iamges | |
| 11:02:02 | sean-k-mooney | with requried traits requests | |
| 11:02:09 | bauzas | new computes can stop reporting a trait, but the prefilter needs to speak old language until next SLURP | |
| 11:02:33 | sean-k-mooney | no that woudl still break explcit traits request in teh flavor/image | |
| 11:02:43 | bauzas | sean-k-mooney: right, but dvo-plv's spec is not exposing the trait itself, which is less tech debt | |
| 11:03:02 | sean-k-mooney | bauzas: it wont require it to be set manually | |
| 11:03:09 | sean-k-mooney | if that is what you mean | |
| 11:03:13 | bauzas | sean-k-mooney: that's why I think we said to avoid as much as possible to expose the traits in flavors | |
| 11:03:23 | sean-k-mooney | partly | |
| 11:03:44 | bauzas | sean-k-mooney: what I mean is that I would strongly disapprove the qemu spec if I hear people using the trait directly in a flavor | |
| 11:03:49 | sean-k-mooney | i dont like askign for things twice (once with a traint and again with an extra spec) | |
| 11:03:58 | bauzas | but I meh it, if we have a prefilter that hides that trait | |
| 11:04:26 | bauzas | operators using that trait directly for scheduling would then do something unsupported | |
| 11:04:27 | sean-k-mooney | right so in general a prefilter or and extention to ResouceRequest.from_request_sepc | |
| 11:04:40 | sean-k-mooney | is the preferd way to use reqirued traits for standard traits | |
| 11:05:10 | sean-k-mooney | ResouceRequest.from_request_spec is what you shoudl extend if its going to be in both the flavor and image | |
| 11:05:13 | bauzas | correct, standard traits should never be used directly in flavors, and I think we said that while ago | |
| 11:05:27 | sean-k-mooney | cool with me | |
| 11:05:41 | bauzas | only custom traits can be used in flavors | |
| 11:05:45 | sean-k-mooney | well | |
| 11:05:53 | bauzas | but I think we never documented that | |
| 11:05:55 | sean-k-mooney | no there are some standard taits that can be in the flavors | |
| 11:06:11 | sean-k-mooney | specificaly the one for cpu fetature flags | |
| 11:06:14 | bauzas | I know, and I'd want us to take a stand | |
| 11:06:24 | sean-k-mooney | i.e. ones that are not related to any flavor extra spec | |
| 11:07:13 | sean-k-mooney | so the nounce is standard traits shodl be avoided if they can be requested via an extra spec instead | |
| 11:07:35 | bauzas | that's sad, PTG is just behind us but I realized we never went to a conclusion on whether we should expose our traits in flavors and the consequences it has | |
| 11:08:20 | sean-k-mooney | well you knwo i generally dont like exposing resouces: or traits in the flavor/image when we can have an indriction via something else | |
| 11:08:37 | bauzas | ditto here, but again, we haven't documented that tenet | |
| 11:09:05 | sean-k-mooney | right but we cant say (you shoudl never request a standard triat in the flvor/image) | |
| 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 | |