Wednesday, 2024-04-10

frickleris the "wildcard search with *" for builds new or did I only just notice it? https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-*&skip=0 is working fine, but something like https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fn*&skip=0 still seems to timeout05:39
fricklerregarding the lost tags issue, I just tried and create a mirror of one of the affected repos on https://try.gitea.io/j-harbott/designate and it looks like all the tags are showing up just fine over there06:12
rpittauclarkb, frickler, fungi, hi! I believe you're global admins, how would I go and change the topic for the ironic channel?07:49
fricklerrpittau: if you tell us the new topic, one of us will happily set it for you. if you expect to do regular topic changes, you can also consider adding yourself to the ops list similar to e.g. https://opendev.org/openstack/project-config/src/branch/master/accessbot/channels.yaml#L167-L16908:25
rpittaufrickler: thanks! I don't think I will be doing regular changes, but I'll keep that in mind08:27
rpittauI just need to change the "Bugs" section to add the launchpad url insted of storyboard, so that part will be: "Bugs: https://launchpad.net/ironic"08:27
*** blarnath is now known as d34dh0r5312:28
fungirpittau: also note that you can add yourself there if you want to, for example, have the ability to kick spammers or other disruptive users from the channel12:54
rpittaufungi: thanks, I'm considering it :)12:55
fungiwe always welcome help with that shared task12:55
fungithere's no rush, the offer's always open12:55
rpittauthank you :)12:56
clarkbfrickler: I suspect that wildcard search stuff is a side effect of the query and/or database changes corvus has done recently14:34
*** gouthamr_ is now known as gouthamr14:35
corvusit's an explicit change: https://zuul-ci.org/docs/zuul/latest/releasenotes.html#new-features14:42
corvusit is possible to create slow queries with it, but it has a timeout to protect the server14:42
fricklercorvus: ah, cool, thx for the pointer. will that be 10.1.0 or 11.0.0? also I guess there won't be any release soon since first the db situation needs to stabilize?15:05
opendevreviewMerged opendev/system-config master: More completely disable ansible galaxy proxy testing  https://review.opendev.org/c/opendev/system-config/+/91518515:17
corvusfrickler: i'm expecting 10.1.0 and yes, i've been kicking the release can down the road as long as we have known bugs (theoretically they are all resolved now, but we'll know for sure next week)15:28
opendevreviewMerged openstack/project-config master: Add ovn charms to charms-stable-maint purview  https://review.opendev.org/c/openstack/project-config/+/90944515:29
opendevreviewMerged opendev/system-config master: Add more LE debugging info to our Ansible role  https://review.opendev.org/c/opendev/system-config/+/91517316:06
fungiheaded out to the hardware store for a few minutes, but should be around again in a bit16:37
opendevreviewClark Boylan proposed opendev/system-config master: Update etherpad to v2.0.2  https://review.opendev.org/c/opendev/system-config/+/91411917:59
opendevreviewClark Boylan proposed opendev/system-config master: DNM force etherpad failure to hold node  https://review.opendev.org/c/opendev/system-config/+/84097217:59
clarkbI've rotated the autohold for this update18:00
fungithanks!18:15
fungijust a heads up, something that came up in the openstack cli/sdk ptg session earlier today is that the openapi work is likely to benefit from a site setup similar to or modeled on https://service-types.openstack.org/18:31
fungithe idea is to have a persistent and continuously updated public location for structured data generated from the various openstack service api endpoints18:32
fungiclarkb: the etherpad upgrade failed on test_etherpad_4_byte_utf818:34
fungilooks like the createPad api call generated an empty stdout18:36
clarkbprobably need to use the held node to debug that18:36
fungiwget exited 618:36
clarkbits possible the new oath stuff breaks the built in admin token18:37
fungithat does seem like the most likely cause18:37
clarkbfungi: that site exists already https://docs.openstack.org/2024.1/api/18:37
clarkbI would just replace what is there with openapi generated specs18:38
clarkbor host it alongside the human curated stuff. But we don't need anything new I don't think18:38
fungiclarkb: that looks like generated documentation, which is something that would also be produced based on the structured data18:38
clarkbya so you'd have a little source button that goes to the .json or whatever18:39
fungibut might not be suitable for things like clients or automation to pull directly18:39
clarkbbasically I'm saying lets not overthink this and just publish where we're already publishing18:39
clarkbhaving yet another location for this data will only create confusion18:39
fungiespecially since it's branched by openstack release, while the client/sdk needs to support all openstack api versions18:39
fungiyeah, build automation could in theory pull copies of structured data from docs.o.o, but that might not be the most intuitive18:40
JayFThe API-Refs contain curated information, not just generated information FWIW18:40
JayFWe cannot directly replace them 1:1, especially not in Ironic's case at least18:41
fungithe original request, which i cautioned against, was to publish the generated api specifications to specs.openstack.org18:41
fungiJayF: it's not api reference documentation they're talking about publishing in this case, it's the structured data that the new sdk would be built from18:41
clarkbya its the json files that could be used to generate docs or sdks or api servers18:42
clarkbI personally think that sort of reference information should go alongside the existing api docs18:42
fungithe current plan that was floated was to scan service api endpoints in order to create structured data representations for each version/microversion, and then transform it into rust (and/or other language bindings) that would be compiled into clients and sdks18:42
clarkbfungi: confirmed there is no APIKEY file in the running container18:43
fungithat's definitely going to complicate matters. most of our admin documentation assumes localhost api access with a static key string18:45
clarkbya and looking at the code the "add oath" commit also removes APIKEY support entirely I think18:47
clarkband then they tagged it .2 instead of 3.x...18:47
clarkbNot sure I have the patience to figure out the new jwt scheme right now18:47
fungilovely18:47
fungiyeah, it's not urgent18:47
clarkb"issuer": "${SSO_ISSUER:http://localhost:9001}", <- from the new config that implies to me that maybe they will issue new tokens in etherpad itself?18:48
fungiprobably worth asking what simple rest api access suitable for command-line interaction would look like now18:48
clarkb"client_secret": "${ADMIN_SECRET:admin}", <- presumably you use that secret to then get a token to then do api requests18:48
fungiso more like the basic tests i set up for keycloak, i guess18:49
clarkbya or zuul client stuff I think18:49
clarkbI'm really not a fan of "completely change how auth works" then tag it as a bug fix release18:49
fungia.k.a. "quietly pull the rug out from under your service operators"18:50
clarkbya looks like all of their internal test cases are updated to run generateJWTToken18:51
fungianyway, https://opendev.org/opendev/system-config/src/branch/master/testinfra/test_keycloak.py#L59-L77 is what it ended up looking like for keycloak but i'm not sure if that's jwt, so maybe the zuul admin api tests are a better fit18:52
clarkbI might revert my change so that we can upgrade to 2.0.1 and then figure this out. I'll have to poke a bit more to decide if the jwt is apinful enough to warrant that18:53
fungiit will definitely also mean we'll need to update https://docs.opendev.org/opendev/system-config/latest/etherpad.html#manual-administrative-tasks18:53
fungithat got pretty messy with using docker-compose to regurgitate the api key, so maybe it will end up no worse18:55
clarkbthe bin/ tools for deleting pads and creating pads etc haven't been updated neigher have the docs18:58
clarkbI think maybe step 0 is filing an issue asking them to correct or clarify that18:58
clarkband take it from there18:58
fungi#status log Pruned backup02.ca-ymq-1.vexxhost reducing backup volume utilization there from 90% to 70%20:35
opendevstatusfungi: finished logging20:35
fungii suspect the failure to merge https://review.opendev.org/910454 was due to jgit's octopus merge issues20:42
fungiit's parent, grandparent, great grandparent...many generations back are all merge commits20:42
fungior else it has a semi-trivial merge conflict cgit's default merge strategy is able to resolve, but zuul's being conservative20:44
tkajinamfungi, I don't know if recent git is smart enough to resolve such conflicting case automatically (and it's very nice if it can)21:05
tkajinamthe problem was that we have a few patches to retire puppet openstack modules and each of these attempted to add one repository to the list of retired repositories. So I think this is the usual conflict case.21:06
fungitkajinam: oh, hah! you're right of course... seems i forgot to `git remote update` before trying to rebase it21:12
fungiso just a regular old merge conflict, move along, nothing to see here21:13

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!