| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-07-02 | |||
| 14:49:35 | amoralej | reading back | |
| 14:49:40 | sean-k-mooney | chandankumar: that woudl be a pr to the nova operator on top of amoralej pr | |
| 14:50:16 | chandankumar | ok | |
| 14:50:34 | sean-k-mooney | i woudl do it like this https://github.com/openstack-k8s-operators/nova-operator/blob/main/ci/nova-operator-tempest-multinode/pre_deploy_hook.yml | |
| 14:50:53 | melwitt | sean-k-mooney: re: the enforce_scope patch, if we can I think it would be better to move it as early in the SRBAC series as we can bc the supposedly deadline for landing it is tomorrow | |
| 14:51:24 | sean-k-mooney | melwitt: that just because it will break us when they do the new oslo release | |
| 14:51:38 | sean-k-mooney | melwitt: but ya let me just do ti against master now | |
| 14:51:44 | sean-k-mooney | melwitt: unless you want to? | |
| 14:51:50 | melwitt | ah gotcha. ok cool | |
| 14:51:51 | amoralej | but you mean out of ci-fw? | |
| 14:52:00 | amoralej | sorry, i'm not following the conversation | |
| 14:52:02 | melwitt | sean-k-mooney: no feel free to go ahead | |
| 14:52:17 | sean-k-mooney | amoralej: yes we shoudl not need to do this isn ci-fw | |
| 14:52:29 | sean-k-mooney | we coudl but why add the extra complexity | |
| 14:52:46 | sean-k-mooney | amoralej: that is the other option do it like the hci-prepare roles | |
| 14:53:10 | amoralej | this is what i did to run cyborg with tempest in edpm job https://github.com/openstack-k8s-operators/nova-operator/pull/1143/changes/689f12f927268a4e94a7e7f8445c149bc3c776ff | |
| 14:53:23 | sean-k-mooney | amoralej: if we do it in the operator its easy to then have a make target in nova-opertor to use it | |
| 14:53:28 | amoralej | i added a ci/nova-operator-cyborg-tempest-multinode/pre_deploy_hook.yml | |
| 14:53:37 | sean-k-mooney | if we do it in ci-fw that make usign the pci-sim lcoally harder | |
| 14:53:39 | amoralej | similar to what you pointed but adding cyborg service | |
| 14:54:24 | sean-k-mooney | amoralej: so yes my soggestion was to buidl on that | |
| 14:54:49 | sean-k-mooney | and add a new pci-sim OpenStackDataPlaneService | |
| 14:55:32 | sean-k-mooney | that will clone the cybrog repo onto the edpm node and compile the pci-sim for cybrog to then use | |
| 14:55:50 | amoralej | ah, got it | |
| 14:55:55 | sean-k-mooney | amoralej: so we can start iwth only the fake driver | |
| 14:56:09 | sean-k-mooney | then once chandankumar has c10s supprot working we can add in the pci-sim | |
| 14:57:13 | sean-k-mooney | chandankumar: amoralej: if we manage to get all that workign how feisbel woudl it be to add a operator job on opendev chagnes? | |
| 14:57:14 | amoralej | iirc, we are still using CS9 in the centos10 jobs used in operators because of some issue | |
| 14:57:41 | sean-k-mooney | oh good to know | |
| 14:58:04 | sean-k-mooney | i guess we will have to resolve that before the year is out one way or another | |
| 14:58:28 | sean-k-mooney | the priorty is devstack c10s supprot then operators after | |
| 14:58:36 | amoralej | yeah, it's CS9, i think chandankumar worked on that, he may remember | |
| 14:58:54 | amoralej | yes, it needs to be fixed somehow | |
| 14:59:46 | sean-k-mooney | i think the issue is realate to the repo setup | |
| 14:59:56 | sean-k-mooney | and or rdo/c10s package aviablity | |
| 15:00:31 | sean-k-mooney | i did try useing c10s recently but didnt debug why it was failing beyound repo-setup | |
| 15:02:14 | chandankumar | on cs10 some packages were not available that time | |
| 15:02:44 | chandankumar | and some config issue i think | |
| 15:03:11 | chandankumar | on dataplane node (I donot exactly remember the details) | |
| 15:04:30 | sean-k-mooney | ya i think it would not neesiarly be hard to fix it just wasnt impornat to fix for what i was doing at the time | |
| 15:05:08 | sean-k-mooney | chandankumar: so we may however defer the edpm supprot for pci-sim | |
| 15:05:13 | sean-k-mooney | until that is resolved | |
| 15:05:42 | sean-k-mooney | we shoudl follow up with that downstream and see if we can get that resolved by the relevent teams | |
| 15:06:04 | chandankumar | ok | |
| 16:43:26 | melwitt | I'm trying out some openstacksdk test stuff https://review.opendev.org/c/openstack/openstacksdk/+/995851 if it goes well I will add more tests and depends-on rlandy's patch | |
| 17:08:21 | sean-k-mooney | oh cool that woudl be cool | |
| 17:13:26 | opendevreview | sean mooney proposed openstack/cyborg master: Adapt Cyborg to always-enforced policy scope https://review.opendev.org/c/openstack/cyborg/+/995867 | |
| 17:13:51 | melwitt | actually I think I could use Needed-By | |
| 17:14:57 | sean-k-mooney | you can | |
| 17:15:06 | sean-k-mooney | we dont have tooling that really sues that | |
| 17:15:30 | sean-k-mooney | Needed-By is jsut for humans today | |
| 17:15:49 | melwitt | oh really? ok I saw it on some gmaan's patches | |
| 17:15:52 | sean-k-mooney | so wither you want to do needed-by or depend on in this case is kind of up to you on merge order | |
| 17:16:15 | sean-k-mooney | ya so we use it for thinks like tackign the steps in new project creation | |
| 17:16:21 | sean-k-mooney | but zuul wont use it for anything | |
| 17:16:34 | melwitt | yeah. I was thinking openstacksdk review pretty quick usually so that's what made me think about it | |
| 17:16:43 | melwitt | ok good to know | |
| 17:17:02 | sean-k-mooney | so it normally is but currently only artem i belive has merge access | |
| 17:17:07 | gmaan | depends-on block the merge but yes needed-by is more of giving a context in commit msg about its need | |
| 17:17:33 | sean-k-mooney | stphenfin is on peternitiy leave for the next 2 weeks then part time after that | |
| 17:17:39 | melwitt | oh ok I thought stephenfin was on there. ok | |
| 17:17:46 | melwitt | ahh ok | |
| 17:17:49 | sean-k-mooney | he is | |
| 17:17:55 | melwitt | I'll use Depends-On then | |
| 17:18:31 | sean-k-mooney | i have +2 rights i belive but no +w so when your happy with it im happy to review | |
| 17:21:53 | sean-k-mooney | melwitt: gmaan https://review.opendev.org/c/openstack/cyborg/+/995867 is the fix for enforce_scope | |
| 17:22:15 | sean-k-mooney | ill rebase my srbac serise on top of that | |
| 17:29:11 | gmaan | lgtm | |
| 18:19:04 | opendevreview | melanie witt proposed openstack/python-cyborgclient master: Add openstacksdk functional test job for accelerator https://review.opendev.org/c/openstack/python-cyborgclient/+/995877 | |
| 19:23:15 | melwitt | openstacksdk tests attempt already uncovered a bug https://bugs.launchpad.net/openstack-cyborg/+bug/2158996 | |
| 20:20:43 | sean-k-mooney | ah fun | |
| 20:20:56 | sean-k-mooney | we can add that to the list of the other db warts | |
| 20:22:40 | sean-k-mooney | melwitt: so i think the atibtues api were actully inteded to add attibutes to devices not deployables | |
| 20:22:51 | sean-k-mooney | i knwo it say deployable_id | |
| 20:23:00 | sean-k-mooney | but if you sue the device id form teh deployse endpoitn | |
| 20:23:03 | sean-k-mooney | i think it might work | |
| 20:23:42 | melwitt | that's whack but I can try it :) | |
| 20:24:09 | sean-k-mooney | hum no | |
| 20:24:11 | sean-k-mooney | https://github.com/openstack/cyborg/blob/master/cyborg/db/sqlalchemy/models.py#L134-L146 | |
| 20:24:17 | sean-k-mooney | it is the deployable id | |
| 20:25:00 | sean-k-mooney | so in the medium term i want to combine the device, deployable and atributes api into a single device api | |
| 20:25:01 | melwitt | ah ok. yeah ... I don't get it | |
| 20:26:19 | sean-k-mooney | there was the idea a long time back that /devices coudl slit any device that cybrog could possibely manage and deployable woudl be the set that could be consumed/programed | |
| 20:26:26 | melwitt | this is pretty cool though, sdk tests are going well overall | |
| 20:26:32 | sean-k-mooney | where each deployablle maps to a placment RP | |
| 20:27:27 | sean-k-mooney | to me spliting device, deployable and atribtues like this has never really made sense | |
| 20:27:27 | melwitt | oh .. so /devices included theoretical devices potentially | |
| 20:28:10 | sean-k-mooney | devices is more the indiviual devices awere as deployables are pools of devices reported to placment | |
| 20:28:42 | sean-k-mooney | kind of like the diffent betwen the pci_deivces table in nova and the pci_stats pools reported to the schduelr | |
| 20:28:50 | melwitt | oh ok | |
| 20:29:21 | sean-k-mooney | but yes in thory you coudl have device in the device tabel that were not reported as usabel but i dont think that is done today | |
| 20:29:48 | sean-k-mooney | basiclly if you say wanted to report all yoru pci devices and then slect which ones can be used via the rest api isntead fo config | |
| 20:30:21 | melwitt | I wonder what is the purpose to list ones that cannot be used? | |
| 20:30:42 | sean-k-mooney | so that you could do an api call to add them to the set that can be used | |
| 20:31:18 | sean-k-mooney | melwitt: basiclly if you reported all of them in the devices api instead of tweakign the ocnfig to enable them to be used you coudl do an api call | |
| 20:31:29 | sean-k-mooney | but i am not a fan of that in general | |
| 20:31:47 | sean-k-mooney | melwitt: the atributes api is pretty new | |
| 20:31:57 | sean-k-mooney | as in 2023? maybe | |
| 20:32:08 | sean-k-mooney | perhsp 2021 | |
| 20:32:22 | sean-k-mooney | i dont think ti was fully implemented properly | |