frickler | is 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 timeout | 05:39 |
---|---|---|
frickler | regarding 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 there | 06:12 |
rpittau | clarkb, frickler, fungi, hi! I believe you're global admins, how would I go and change the topic for the ironic channel? | 07:49 |
frickler | rpittau: 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-L169 | 08:25 |
rpittau | frickler: thanks! I don't think I will be doing regular changes, but I'll keep that in mind | 08:27 |
rpittau | I 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 d34dh0r53 | 12:28 | |
fungi | rpittau: 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 channel | 12:54 |
rpittau | fungi: thanks, I'm considering it :) | 12:55 |
fungi | we always welcome help with that shared task | 12:55 |
fungi | there's no rush, the offer's always open | 12:55 |
rpittau | thank you :) | 12:56 |
clarkb | frickler: I suspect that wildcard search stuff is a side effect of the query and/or database changes corvus has done recently | 14:34 |
*** gouthamr_ is now known as gouthamr | 14:35 | |
corvus | it's an explicit change: https://zuul-ci.org/docs/zuul/latest/releasenotes.html#new-features | 14:42 |
corvus | it is possible to create slow queries with it, but it has a timeout to protect the server | 14:42 |
frickler | corvus: 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 |
opendevreview | Merged opendev/system-config master: More completely disable ansible galaxy proxy testing https://review.opendev.org/c/opendev/system-config/+/915185 | 15:17 |
corvus | frickler: 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 |
opendevreview | Merged openstack/project-config master: Add ovn charms to charms-stable-maint purview https://review.opendev.org/c/openstack/project-config/+/909445 | 15:29 |
opendevreview | Merged opendev/system-config master: Add more LE debugging info to our Ansible role https://review.opendev.org/c/opendev/system-config/+/915173 | 16:06 |
fungi | headed out to the hardware store for a few minutes, but should be around again in a bit | 16:37 |
opendevreview | Clark Boylan proposed opendev/system-config master: Update etherpad to v2.0.2 https://review.opendev.org/c/opendev/system-config/+/914119 | 17:59 |
opendevreview | Clark Boylan proposed opendev/system-config master: DNM force etherpad failure to hold node https://review.opendev.org/c/opendev/system-config/+/840972 | 17:59 |
clarkb | I've rotated the autohold for this update | 18:00 |
fungi | thanks! | 18:15 |
fungi | just 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 |
fungi | the idea is to have a persistent and continuously updated public location for structured data generated from the various openstack service api endpoints | 18:32 |
fungi | clarkb: the etherpad upgrade failed on test_etherpad_4_byte_utf8 | 18:34 |
fungi | looks like the createPad api call generated an empty stdout | 18:36 |
clarkb | probably need to use the held node to debug that | 18:36 |
fungi | wget exited 6 | 18:36 |
clarkb | its possible the new oath stuff breaks the built in admin token | 18:37 |
fungi | that does seem like the most likely cause | 18:37 |
clarkb | fungi: that site exists already https://docs.openstack.org/2024.1/api/ | 18:37 |
clarkb | I would just replace what is there with openapi generated specs | 18:38 |
clarkb | or host it alongside the human curated stuff. But we don't need anything new I don't think | 18:38 |
fungi | clarkb: that looks like generated documentation, which is something that would also be produced based on the structured data | 18:38 |
clarkb | ya so you'd have a little source button that goes to the .json or whatever | 18:39 |
fungi | but might not be suitable for things like clients or automation to pull directly | 18:39 |
clarkb | basically I'm saying lets not overthink this and just publish where we're already publishing | 18:39 |
clarkb | having yet another location for this data will only create confusion | 18:39 |
fungi | especially since it's branched by openstack release, while the client/sdk needs to support all openstack api versions | 18:39 |
fungi | yeah, build automation could in theory pull copies of structured data from docs.o.o, but that might not be the most intuitive | 18:40 |
JayF | The API-Refs contain curated information, not just generated information FWIW | 18:40 |
JayF | We cannot directly replace them 1:1, especially not in Ironic's case at least | 18:41 |
fungi | the original request, which i cautioned against, was to publish the generated api specifications to specs.openstack.org | 18:41 |
fungi | JayF: 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 from | 18:41 |
clarkb | ya its the json files that could be used to generate docs or sdks or api servers | 18:42 |
clarkb | I personally think that sort of reference information should go alongside the existing api docs | 18:42 |
fungi | the 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 sdks | 18:42 |
clarkb | fungi: confirmed there is no APIKEY file in the running container | 18:43 |
fungi | that's definitely going to complicate matters. most of our admin documentation assumes localhost api access with a static key string | 18:45 |
clarkb | ya and looking at the code the "add oath" commit also removes APIKEY support entirely I think | 18:47 |
clarkb | and then they tagged it .2 instead of 3.x... | 18:47 |
clarkb | Not sure I have the patience to figure out the new jwt scheme right now | 18:47 |
fungi | lovely | 18:47 |
fungi | yeah, it's not urgent | 18: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 |
fungi | probably worth asking what simple rest api access suitable for command-line interaction would look like now | 18:48 |
clarkb | "client_secret": "${ADMIN_SECRET:admin}", <- presumably you use that secret to then get a token to then do api requests | 18:48 |
fungi | so more like the basic tests i set up for keycloak, i guess | 18:49 |
clarkb | ya or zuul client stuff I think | 18:49 |
clarkb | I'm really not a fan of "completely change how auth works" then tag it as a bug fix release | 18:49 |
fungi | a.k.a. "quietly pull the rug out from under your service operators" | 18:50 |
clarkb | ya looks like all of their internal test cases are updated to run generateJWTToken | 18:51 |
fungi | anyway, 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 fit | 18:52 |
clarkb | I 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 that | 18:53 |
fungi | it will definitely also mean we'll need to update https://docs.opendev.org/opendev/system-config/latest/etherpad.html#manual-administrative-tasks | 18:53 |
fungi | that got pretty messy with using docker-compose to regurgitate the api key, so maybe it will end up no worse | 18:55 |
clarkb | the bin/ tools for deleting pads and creating pads etc haven't been updated neigher have the docs | 18:58 |
clarkb | I think maybe step 0 is filing an issue asking them to correct or clarify that | 18:58 |
clarkb | and take it from there | 18:58 |
fungi | #status log Pruned backup02.ca-ymq-1.vexxhost reducing backup volume utilization there from 90% to 70% | 20:35 |
opendevstatus | fungi: finished logging | 20:35 |
fungi | i suspect the failure to merge https://review.opendev.org/910454 was due to jgit's octopus merge issues | 20:42 |
fungi | it's parent, grandparent, great grandparent...many generations back are all merge commits | 20:42 |
fungi | or else it has a semi-trivial merge conflict cgit's default merge strategy is able to resolve, but zuul's being conservative | 20:44 |
tkajinam | fungi, 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 |
tkajinam | the 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 |
fungi | tkajinam: oh, hah! you're right of course... seems i forgot to `git remote update` before trying to rebase it | 21:12 |
fungi | so just a regular old merge conflict, move along, nothing to see here | 21:13 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!