| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-07-02 | |||
| 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 | |
| 20:32:39 | sean-k-mooney | so im not surpsied that there are bugs like that | |
| 20:32:49 | sean-k-mooney | i.e. that it need the db id instead of uuid | |
| 20:33:13 | melwitt | yeah. it's interesting because how did they get the db id assuming someone used this | |
| 20:33:56 | sean-k-mooney | so i think there is a way | |
| 20:34:20 | sean-k-mooney | the placement resouce class i think is alwasy reported as an atribute | |
| 20:34:34 | sean-k-mooney | so fi you do a `GET /v2/attributes` | |
| 20:34:50 | sean-k-mooney | that return the deployable_id as an int | |
| 20:35:19 | sean-k-mooney | hum no | |
| 20:35:55 | sean-k-mooney | that dill does nto allow you to corrlate back to the deployable | |
| 20:37:07 | sean-k-mooney | melwitt: so genera question how do we fix that. | |
| 20:37:26 | sean-k-mooney | because we are fixing a 500 we are technially allwoed to do it without a microverion | |
| 20:37:43 | melwitt | yeah ... there isn't an obvious answer how bc it's so strange | |
| 20:37:46 | sean-k-mooney | i woudl be included to make it only work iwth the uuid if im being honest | |
| 20:38:03 | sean-k-mooney | since the db primary key is inteded to be internal | |
| 20:38:08 | melwitt | yeah | |
| 20:38:31 | sean-k-mooney | i guess we dont need to answer that now | |
| 20:38:52 | melwitt | yeah I put a skip on that test and reference the bug | |
| 20:38:54 | sean-k-mooney | we coudl accpet either and hten stop accapting the id in a future microverion | |
| 20:40:07 | 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:28 | sean-k-mooney | https://review.opendev.org/c/openstack/cyborg/+/869150 no tests :) | |
| 20:40:46 | sean-k-mooney | melwitt: ya we just need to make sure we also swap it in the responce | |
| 20:40:59 | sean-k-mooney | so the responce shoudl also reuttin the uuid for the deployable | |
| 20:41:34 | melwitt | yeah | |
| 20:43:26 | sean-k-mooney | https://specs.openstack.org/openstack/cyborg-specs/specs/2023.2/implemented/attribute-api-support.html | |
| 20:43:33 | sean-k-mooney | so the spec was only partly implemited | |
| 20:43:54 | sean-k-mooney | you are ment to be abel to acces the atributs vai /v2/deployable/{uuid}/attribute | |
| 20:44:19 | sean-k-mooney | and that is how you are ment to add/remove them | |
| 20:44:43 | sean-k-mooney | that actully alot clsoer wo how i wanted to evolve the api | |
| 20:45:56 | 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:48:38 | 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:54 | sean-k-mooney | yep | |
| 20:49:06 | sean-k-mooney | atribtue wer enot inteded to be a top level resouce | |
| 20:49:11 | melwitt | or I guess maybe only allow listing or getting. I dunno | |
| 20:49:16 | melwitt | ok | |
| 20:49:20 | sean-k-mooney | they were emnt to be a sub resocue to allow you to add and remove placment trait form dpeloyables | |
| 20:50:11 | sean-k-mooney | ok dinner is ready so im going to go | |
| 20:50:22 | melwitt | ok, ttyl | |
| 20:51:23 | 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:36 | sean-k-mooney | unless you end up doing it first :) | |
| 20:52:00 | sean-k-mooney | melwitt: i think we actully came across this issue a few weeks ago by the way | |
| 20:52:11 | sean-k-mooney | right around 2026.1 FF | |
| 20:52:18 | melwitt | a-ha :) | |
| 20:52:26 | sean-k-mooney | i just didnt get around to writing this down | |
| 20:53:13 | sean-k-mooney | o/ | |
| 20:53:29 | melwitt | o/ | |
| 22:16:33 | 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:17:43 | sean-k-mooney[m] | Cool I'll probably get to it on monday | |
| 22:18:16 | sean-k-mooney[m] | Can you add me to them in gerrit | |
| 22:18:46 | melwitt | sure | |
| 22:19:02 | melwitt | (sorry that was meant to be a async message) | |
| 22:21:11 | sean-k-mooney[m] | I'm just walking home | |
| 22:21:33 | sean-k-mooney[m] | So your not interrupting | |