| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 10:46:01 | sean-k-mooney | i have been debating about doing that | |
| 10:46:51 | bauzas | sean-k-mooney: btw. when you and dansmith have time, I'd like to discuss on what direction we should do with https://bugs.launchpad.net/nova/+bug/2041519 | |
| 10:47:21 | bauzas | the alternative series I wrote is not helping as it doesn't delete existing RPs https://review.opendev.org/q/topic:bug%252F2041519-new | |
| 10:47:59 | bauzas | (the above patch is just a nice try to pass a PF in device_addr instead of VFs, but that's not mandatory) | |
| 10:49:00 | sean-k-mooney | ok ill need to load context on this again so let either set up a meeting ro choose a time to discuss it but it woudl be good to sumemrise what you have tried and what did/didnt work | |
| 10:49:20 | bauzas | sean-k-mooney: and you know, I haven't darken my view of the world, I'm just mattman as matthew perry said | |
| 10:49:23 | sean-k-mooney | bauzas: im currently reviewing dans spec | |
| 10:49:30 | sean-k-mooney | but i can take a look at the patches after | |
| 10:49:42 | bauzas | sean-k-mooney: sure, let's do a gmeet with dan when he's up | |
| 10:49:46 | zigo | jrosser: Am I reading well that the A100 removal is from the Linux kernel ?!? | |
| 10:49:49 | bauzas | sean-k-mooney: no urgency | |
| 10:50:14 | bauzas | zigo: no, A100 are no longer supported in GRID, that's the point | |
| 10:50:14 | sean-k-mooney | zigo: i dont think soo i think its just being droped form the nvidia binary driver they ship via there portal | |
| 10:50:26 | bauzas | zigo: starting with GRID16 | |
| 10:50:44 | bauzas | https://docs.nvidia.com/grid/16.0/whats-new-vgpu/index.html | |
| 10:50:44 | sean-k-mooney | it would work as a normal graphics card with teh opensouce neuvous driver | |
| 10:50:54 | dvo-plv | Hello, All. I would like to discuss results of yesterday debate regarding packed ring. Currently we have tow way traits and prefilter based on the release version. How we properly can solve this problem, Should be ask gibi for his ? | |
| 10:51:04 | sean-k-mooney | but none of there vGPU stuff is supproted in the the opensouce dirver | |
| 10:51:15 | bauzas | dvo-plv: I said yesterday that eventually, I'll let the spec sail | |
| 10:51:24 | bauzas | so ask gibi for a review | |
| 10:52:15 | bauzas | dvo-plv: sean-k-mooney had a point on the fact we shouldn't conditionnally provide the trait, so update your spec and add testing and I'll let sean-k-mooney +2 it | |
| 10:52:42 | dvo-plv | okay, I see your point, thank you | |
| 10:52:45 | bauzas | for me, I'll pass as I don't want to give an approval for some direction I have arguments against, but on the other way, I don't wanna hold the series, so I defer to other cores | |
| 10:53:02 | sean-k-mooney | dvo-plv: tl;dr we bumped libvirt min to 7.0.0 last cycle so no need to do a check on the version anymore | |
| 10:53:02 | bauzas | I'll just not vote on the spec | |
| 10:53:09 | sean-k-mooney | either for the trait or in the driver | |
| 10:53:20 | sean-k-mooney | you can just assume its new enough | |
| 10:54:02 | dvo-plv | yes, i remember your comment under the nova patch, that i have to update it, because this https://review.opendev.org/c/openstack/nova/+/887255 was merge first | |
| 10:54:19 | bauzas | correct | |
| 10:54:26 | sean-k-mooney | yep | |
| 10:54:47 | sean-k-mooney | it should simplfy your patch although you had already added the checks | |
| 10:55:06 | dvo-plv | sure, i will update spec first and then nova. Thank you for your time | |
| 10:55:38 | bauzas | dvo-plv: fwiw, even if I want to abstain on the spec, I can review the implementation | |
| 10:56:06 | bauzas | now that I have the whole context, I surely can review it quickly once the design is approved by other cores but me | |
| 10:56:14 | dvo-plv | sure | |
| 10:56:35 | dvo-plv | it sounds critical:) | |
| 10:57:01 | zigo | Namely, cloudkitty, trove, ironic-inspector, masakari, sahara, senlin, vitrage, zaqar ... | |
| 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: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 | |