| opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | 04:23 |
|---|---|---|
| chandankumar | sean-k-mooney: hello, Feel free to take a look at https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/992330 and https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/992339 when free. | 08:23 |
| chandankumar | Rest of the patches in this series looks good to merge! | 08:24 |
| opendevreview | Ronelle Landy proposed openstack/python-cyborgclient master: Remove deprecated v1 API and fix Python 3.12+ SSL compatibility https://review.opendev.org/c/openstack/python-cyborgclient/+/995789 | 09:19 |
| sean-k-mooney | chandankumar: thanks for the reminder ill try and adress those today | 10:50 |
| opendevreview | Merged openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | 11:24 |
| opendevreview | Merged openstack/cyborg-specs master: Add generic mdev driver spec for 2026.2 https://review.opendev.org/c/openstack/cyborg-specs/+/982276 | 11:24 |
| opendevreview | Ronelle Landy proposed openstack/python-cyborgclient master: Remove deprecated v1 API and fix Python 3.12+ SSL compatibility https://review.opendev.org/c/openstack/python-cyborgclient/+/995789 | 11:45 |
| sean-k-mooney | chandankumar: oh your right https://review.opendev.org/c/openstack/cyborg/+/994577?tab=change-view-tab-header-zuul-results-summary is not enabling the new tests as exected beasue i have not added the depens on | 14:32 |
| sean-k-mooney | i have doen that in my srbac serise so i need to fix that | 14:32 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cyborg/+/992332/6 | 14:33 |
| chandankumar | sean-k-mooney: this week I am also thinking to port pci-sim on cs10 it will help to integrate it with install yamls and tests stuff using pci-driver | 14:37 |
| sean-k-mooney | well im not sure we shoudl need to modify install yamls | 14:38 |
| sean-k-mooney | but sure | 14:38 |
| sean-k-mooney | i was exectign to just have a playbook for this in the nova-operator repo in the ci folder | 14:38 |
| sean-k-mooney | i dont think addign c10s supprot will be hard persay just need to gernalise how we isntall the depenciences | 14:39 |
| sean-k-mooney | chandankumar: when working on that it might make sense to add a c10s ro rocky/alma job to the expermiental and weekly lines | 14:40 |
| sean-k-mooney | upsteam | 14:40 |
| chandankumar | playbook idea is also fine | 14:40 |
| chandankumar | sure, let me get the patch up. | 14:41 |
| sean-k-mooney | so i was thinking a playbooks and or make target to do it but whatever works. i generally dont like useing insall_yamls for much | 14:41 |
| sean-k-mooney | i mean its fine its just a prefernce | 14:42 |
| sean-k-mooney | the reason i was thinkign a playbook | 14:42 |
| sean-k-mooney | is my over all plan was to define a custom datapalen service that woudl run it on the edpm nodes as part of the dataplane deploy | 14:43 |
| sean-k-mooney | so we woudl then just havea kustomization that added that custom datapalen service to the node set the way repo setup works | 14:44 |
| sean-k-mooney | so rather then a freestanding playbook defiening it inline within the dataplaen sevice might be the best approch | 14:45 |
| sean-k-mooney | or do it wih kustomize | 14:45 |
| chandankumar | yes, custo kustomization repo setup seems to be much better | 14:46 |
| sean-k-mooney | in either case wi twoudl be trivial to have a make target that just does an oc apply -k/-f to defien the serice and it easy to then add that to the dataplane node set | 14:46 |
| sean-k-mooney | i assume you were thinking it woudl jsut clone the cybrog repo if not present on the edpm ndoe and then do the compile caling the devstack plugin directly or simialr. | 14:47 |
| sean-k-mooney | actully it does nto really need to do that | 14:47 |
| sean-k-mooney | it can just use the make targets | 14:47 |
| chandankumar | yes, clone and run make target | 14:48 |
| sean-k-mooney | ya ok | 14:48 |
| sean-k-mooney | i think that works | 14:48 |
| sean-k-mooney | if you can get that workign on c10s after you get the devstack version done that would be cool | 14:48 |
| sean-k-mooney | amoralej: ^ | 14:48 |
| sean-k-mooney | does that sound good to you | 14:49 |
| amoralej | reading back | 14:49 |
| sean-k-mooney | chandankumar: that woudl be a pr to the nova operator on top of amoralej pr | 14:49 |
| chandankumar | ok | 14:50 |
| 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 |
| 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:50 |
| sean-k-mooney | melwitt: that just because it will break us when they do the new oslo release | 14:51 |
| sean-k-mooney | melwitt: but ya let me just do ti against master now | 14:51 |
| sean-k-mooney | melwitt: unless you want to? | 14:51 |
| melwitt | ah gotcha. ok cool | 14:51 |
| amoralej | but you mean out of ci-fw? | 14:51 |
| amoralej | sorry, i'm not following the conversation | 14:52 |
| melwitt | sean-k-mooney: no feel free to go ahead | 14:52 |
| sean-k-mooney | amoralej: yes we shoudl not need to do this isn ci-fw | 14:52 |
| sean-k-mooney | we coudl but why add the extra complexity | 14:52 |
| sean-k-mooney | amoralej: that is the other option do it like the hci-prepare roles | 14:52 |
| 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 |
| 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 |
| amoralej | i added a ci/nova-operator-cyborg-tempest-multinode/pre_deploy_hook.yml | 14:53 |
| sean-k-mooney | if we do it in ci-fw that make usign the pci-sim lcoally harder | 14:53 |
| amoralej | similar to what you pointed but adding cyborg service | 14:53 |
| sean-k-mooney | amoralej: so yes my soggestion was to buidl on that | 14:54 |
| sean-k-mooney | and add a new pci-sim OpenStackDataPlaneService | 14:54 |
| 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 |
| amoralej | ah, got it | 14:55 |
| sean-k-mooney | amoralej: so we can start iwth only the fake driver | 14:55 |
| sean-k-mooney | then once chandankumar has c10s supprot working we can add in the pci-sim | 14:56 |
| 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 |
| amoralej | iirc, we are still using CS9 in the centos10 jobs used in operators because of some issue | 14:57 |
| sean-k-mooney | oh good to know | 14:57 |
| sean-k-mooney | i guess we will have to resolve that before the year is out one way or another | 14:58 |
| sean-k-mooney | the priorty is devstack c10s supprot then operators after | 14:58 |
| amoralej | yeah, it's CS9, i think chandankumar worked on that, he may remember | 14:58 |
| amoralej | yes, it needs to be fixed somehow | 14:58 |
| sean-k-mooney | i think the issue is realate to the repo setup | 14:59 |
| sean-k-mooney | and or rdo/c10s package aviablity | 14:59 |
| sean-k-mooney | i did try useing c10s recently but didnt debug why it was failing beyound repo-setup | 15:00 |
| chandankumar | on cs10 some packages were not available that time | 15:02 |
| chandankumar | and some config issue i think | 15:02 |
| chandankumar | on dataplane node (I donot exactly remember the details) | 15:03 |
| 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:04 |
| sean-k-mooney | chandankumar: so we may however defer the edpm supprot for pci-sim | 15:05 |
| sean-k-mooney | until that is resolved | 15:05 |
| sean-k-mooney | we shoudl follow up with that downstream and see if we can get that resolved by the relevent teams | 15:05 |
| chandankumar | ok | 15:06 |
| 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 | 16:43 |
| sean-k-mooney | oh cool that woudl be cool | 17:08 |
| opendevreview | sean mooney proposed openstack/cyborg master: Adapt Cyborg to always-enforced policy scope https://review.opendev.org/c/openstack/cyborg/+/995867 | 17:13 |
| melwitt | actually I think I could use Needed-By | 17:13 |
| sean-k-mooney | you can | 17:14 |
| sean-k-mooney | we dont have tooling that really sues that | 17:15 |
| sean-k-mooney | Needed-By is jsut for humans today | 17:15 |
| melwitt | oh really? ok I saw it on some gmaan's patches | 17:15 |
| 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:15 |
| sean-k-mooney | ya so we use it for thinks like tackign the steps in new project creation | 17:16 |
| sean-k-mooney | but zuul wont use it for anything | 17:16 |
| melwitt | yeah. I was thinking openstacksdk review pretty quick usually so that's what made me think about it | 17:16 |
| melwitt | ok good to know | 17:16 |
| sean-k-mooney | so it normally is but currently only artem i belive has merge access | 17:17 |
| gmaan | depends-on block the merge but yes needed-by is more of giving a context in commit msg about its need | 17:17 |
| sean-k-mooney | stphenfin is on peternitiy leave for the next 2 weeks then part time after that | 17:17 |
| melwitt | oh ok I thought stephenfin was on there. ok | 17:17 |
| melwitt | ahh ok | 17:17 |
| sean-k-mooney | he is | 17:17 |
| melwitt | I'll use Depends-On then | 17:17 |
| sean-k-mooney | i have +2 rights i belive but no +w so when your happy with it im happy to review | 17:18 |
| sean-k-mooney | melwitt: gmaan https://review.opendev.org/c/openstack/cyborg/+/995867 is the fix for enforce_scope | 17:21 |
| sean-k-mooney | ill rebase my srbac serise on top of that | 17:22 |
| gmaan | lgtm | 17:29 |
| opendevreview | melanie witt proposed openstack/python-cyborgclient master: Add openstacksdk functional test job for accelerator https://review.opendev.org/c/openstack/python-cyborgclient/+/995877 | 18:19 |
| melwitt | openstacksdk tests attempt already uncovered a bug https://bugs.launchpad.net/openstack-cyborg/+bug/2158996 | 19:23 |
| sean-k-mooney | ah fun | 20:20 |
| sean-k-mooney | we can add that to the list of the other db warts | 20:20 |
| sean-k-mooney | melwitt: so i think the atibtues api were actully inteded to add attibutes to devices not deployables | 20:22 |
| sean-k-mooney | i knwo it say deployable_id | 20:22 |
| sean-k-mooney | but if you sue the device id form teh deployse endpoitn | 20:23 |
| sean-k-mooney | i think it might work | 20:23 |
| * melwitt looks | 20:23 | |
| melwitt | that's whack but I can try it :) | 20:23 |
| sean-k-mooney | hum no | 20:24 |
| sean-k-mooney | https://github.com/openstack/cyborg/blob/master/cyborg/db/sqlalchemy/models.py#L134-L146 | 20:24 |
| sean-k-mooney | it is the deployable id | 20:24 |
| 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 |
| melwitt | ah ok. yeah ... I don't get it | 20:25 |
| 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 |
| melwitt | this is pretty cool though, sdk tests are going well overall | 20:26 |
| sean-k-mooney | where each deployablle maps to a placment RP | 20:26 |
| melwitt | oh .. so /devices included theoretical devices potentially | 20:27 |
| sean-k-mooney | to me spliting device, deployable and atribtues like this has never really made sense | 20:27 |
| sean-k-mooney | devices is more the indiviual devices awere as deployables are pools of devices reported to placment | 20:28 |
| 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 |
| melwitt | oh ok | 20:28 |
| 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 |
| 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:29 |
| melwitt | I wonder what is the purpose to list ones that cannot be used? | 20:30 |
| sean-k-mooney | so that you could do an api call to add them to the set that can be used | 20:30 |
| 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 |
| sean-k-mooney | but i am not a fan of that in general | 20:31 |
| sean-k-mooney | melwitt: the atributes api is pretty new | 20:31 |
| sean-k-mooney | as in 2023? maybe | 20:31 |
| sean-k-mooney | perhsp 2021 | 20:32 |
| sean-k-mooney | i dont think ti was fully implemented properly | 20:32 |
| sean-k-mooney | so im not surpsied that there are bugs like that | 20:32 |
| sean-k-mooney | i.e. that it need the db id instead of uuid | 20:32 |
| melwitt | yeah. it's interesting because how did they get the db id assuming someone used this | 20:33 |
| sean-k-mooney | so i think there is a way | 20:33 |
| sean-k-mooney | the placement resouce class i think is alwasy reported as an atribute | 20:34 |
| sean-k-mooney | so fi you do a `GET /v2/attributes` | 20:34 |
| sean-k-mooney | that return the deployable_id as an int | 20:34 |
| sean-k-mooney | hum no | 20:35 |
| sean-k-mooney | that dill does nto allow you to corrlate back to the deployable | 20:35 |
| sean-k-mooney | melwitt: so genera question how do we fix that. | 20:37 |
| sean-k-mooney | because we are fixing a 500 we are technially allwoed to do it without a microverion | 20:37 |
| melwitt | yeah ... there isn't an obvious answer how bc it's so strange | 20:37 |
| sean-k-mooney | i woudl be included to make it only work iwth the uuid if im being honest | 20:37 |
| sean-k-mooney | since the db primary key is inteded to be internal | 20:38 |
| melwitt | yeah | 20:38 |
| sean-k-mooney | i guess we dont need to answer that now | 20:38 |
| melwitt | yeah I put a skip on that test and reference the bug | 20:38 |
| sean-k-mooney | we coudl accpet either and hten stop accapting the id in a future microverion | 20:38 |
| melwitt | I think one could argue to just switch it over bc there seems no realistic way an API caller could get the DB primary key but I might be missing something | 20:40 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cyborg/+/869150 no tests :) | 20:40 |
| sean-k-mooney | melwitt: ya we just need to make sure we also swap it in the responce | 20:40 |
| sean-k-mooney | so the responce shoudl also reuttin the uuid for the deployable | 20:40 |
| melwitt | yeah | 20:41 |
| sean-k-mooney | https://specs.openstack.org/openstack/cyborg-specs/specs/2023.2/implemented/attribute-api-support.html | 20:43 |
| sean-k-mooney | so the spec was only partly implemited | 20:43 |
| sean-k-mooney | you are ment to be abel to acces the atributs vai /v2/deployable/{uuid}/attribute | 20:43 |
| sean-k-mooney | and that is how you are ment to add/remove them | 20:44 |
| sean-k-mooney | that actully alot clsoer wo how i wanted to evolve the api | 20:44 |
| sean-k-mooney | melwitt: im almost tempeted to revert out the current atribtues api and implemnt it properly since it does not work and it does not match the spec | 20:45 |
| melwitt | I guess if that's how it was meant to be implemented ... could flesh that out and then maybe deprecate /attributes potentially? | 20:48 |
| sean-k-mooney | yep | 20:48 |
| sean-k-mooney | atribtue wer enot inteded to be a top level resouce | 20:49 |
| melwitt | or I guess maybe only allow listing or getting. I dunno | 20:49 |
| melwitt | ok | 20:49 |
| sean-k-mooney | they were emnt to be a sub resocue to allow you to add and remove placment trait form dpeloyables | 20:49 |
| sean-k-mooney | ok dinner is ready so im going to go | 20:50 |
| melwitt | ok, ttyl | 20:50 |
| sean-k-mooney | i think in advacce for the next ptg im going to spend some time prepareing a spec for all of the api techinial debt so we can have a singel microversion ot correct all of this | 20:51 |
| sean-k-mooney | unless you end up doing it first :) | 20:51 |
| sean-k-mooney | melwitt: i think we actully came across this issue a few weeks ago by the way | 20:52 |
| sean-k-mooney | right around 2026.1 FF | 20:52 |
| melwitt | a-ha :) | 20:52 |
| sean-k-mooney | i just didnt get around to writing this down | 20:52 |
| sean-k-mooney | o/ | 20:53 |
| melwitt | o/ | 20:53 |
| melwitt | sean-k-mooney: I think https://review.opendev.org/c/openstack/openstacksdk/+/995851 is ready for review now and I have https://review.opendev.org/c/openstack/python-cyborgclient/+/995877 depends-on it to run the job on the client | 22:16 |
| sean-k-mooney[m] | Cool I'll probably get to it on monday | 22:17 |
| sean-k-mooney[m] | Can you add me to them in gerrit | 22:18 |
| melwitt | sure | 22:18 |
| melwitt | (sorry that was meant to be a async message) | 22:19 |
| sean-k-mooney[m] | I'm just walking home | 22:21 |
| sean-k-mooney[m] | So your not interrupting | 22:21 |
| melwitt | ok good | 22:21 |
| opendevreview | sean mooney proposed openstack/cyborg master: Adapt Cyborg to always-enforced policy scope https://review.opendev.org/c/openstack/cyborg/+/995867 | 22:38 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!