| clarkb | as a heads up I'm going to try and run an errand before our meeting tomorrow. Place opens at 11am local and meeting is at noon local. I should have plenty of time if I get there when they open but if not then I may be a little late | 14:56 |
|---|---|---|
| clarkb | infra-root https://review.opendev.org/c/opendev/base-jobs/+/929962 fixes CI on opendev/base-jobs. Then the child change may be of interest too (since the whole OVN DNS mitm thing irks me) | 14:57 |
| opendevreview | Merged opendev/base-jobs master: Fixup CI jobs https://review.opendev.org/c/opendev/base-jobs/+/929962 | 15:13 |
| clarkb | keep an eye out for unexpected behavors from ^ they should all be equivalent though | 15:14 |
| fungi | will do | 15:26 |
| fungi | gonna disappear briefly to grab lunch and then maybe start poking at the mm3 upgrade | 15:26 |
| clarkb | I really wish systems didn't try to phone home and check if the latest version is available | 15:33 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Etherpad to v2.2.5 https://review.opendev.org/c/opendev/system-config/+/930215 | 15:38 |
| opendevreview | Clark Boylan proposed opendev/system-config master: DNM force etherpad failure to hold node https://review.opendev.org/c/opendev/system-config/+/840972 | 15:39 |
| clarkb | autohold is in place for ^ | 15:40 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Gitea to v1.22.2 https://review.opendev.org/c/opendev/system-config/+/930217 | 15:45 |
| fungi | clarkb: which system is phoning home now? | 16:58 |
| clarkb | fungi: etherpad (it has been but they made the location configurable now so its more noticeable that it does so) | 16:59 |
| clarkb | I wrote a note about it in 930215 | 16:59 |
| fungi | oh fun, i didn't even realize it was doing that! | 16:59 |
| clarkb | it checks what the latest version of etherpad is in order to log whether or not you need to upgrade | 17:00 |
| clarkb | https://etherpad.org/ep_infos/info.json is what it fetches | 17:02 |
| clarkb | 217.182.142.68 is the held etherpad 2.2.5 node. I'm testing it now in the clarkb-test pad | 17:18 |
| clarkb | It seems to be working | 17:20 |
| clarkb | I've just realized that the new api-docs swagger path will need a proxy override as long as we don't already have a pad called api-docs | 17:20 |
| clarkb | do we want to proxy that or not? I could go either way on it myself | 17:21 |
| clarkb | I'm going to quickly update the held node by hand just to make sure that that functionality works | 17:21 |
| fungi | predictably, https://etherpad.opendev.org/p/api-docs is already a thing in our production instance | 17:21 |
| fungi | timeslider indicates it was last edited in 2013, 11 years ago | 17:22 |
| fungi | looks like it was for an "informal unconference" session at the... portland? summit | 17:23 |
| fungi | 'Where: At the tables above the Pendulum on the "A" side of the convention center' | 17:23 |
| fungi | i think that space had an "a" and "b" side | 17:24 |
| fungi | or maybe not, that one had an upstairs where we did the design summit sessions and a downstairs for the main sessions | 17:24 |
| fungi | maybe this was san diego | 17:25 |
| fungi | it was portland | 17:25 |
| fungi | just correlated the dates | 17:25 |
| clarkb | looks like we need to do /api-docs/.* and /api-docs.json at a minimum | 17:26 |
| clarkb | fungi: the old pad would still be reachable using /p/ | 17:26 |
| fungi | yeah, i think that's fine then | 17:26 |
| clarkb | I confirmed on the test node that adding those two exclusions make the swagger stuff work | 17:26 |
| clarkb | ok I'll respin and recycle the hold. Then we can retest | 17:27 |
| fungi | i'll hold off testing in that case | 17:27 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Etherpad to v2.2.5 https://review.opendev.org/c/opendev/system-config/+/930215 | 17:29 |
| 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:29 |
| clarkb | the /p/ redirect for pads is a permanent redirect which made testing that after caching the wrong thing interesting | 17:31 |
| clarkb | anyway I've recycled things | 17:31 |
| fungi | yeah, so any links to https://etherpad.opendev.org/api-docs have had a decade and then some to be fixed | 17:34 |
| clarkb | fungi: well in this case we're only special casing /api-docs/ so it should work out I hope | 17:36 |
| clarkb | a bit annoying if you're looking for the swagger docs and forget the trailing / but a reasonable compromise given the situation | 17:36 |
| fungi | SURE | 17:42 |
| fungi | gah, capslock strikes again! | 17:42 |
| clarkb | the gitea upgrade change passed testing. I didn't hold a node for that as historically we haven't done so for the minor bugfix updates | 17:55 |
| clarkb | let me know if you think we should though (probably one reason to do so is if we want to be extra careful around the openstack release) | 17:56 |
| fungi | amusingly, the latest mailman dockerfiles use `pip install --break-system-packages ...` | 18:05 |
| clarkb | fungi: any thoughts on https://review.opendev.org/c/opendev/base-jobs/+/929960 and whether or not we should pursue that furhter? In particular I'm hoping for a sanity check that we want this before I set up a base-test update with a test role just to test that | 18:25 |
| clarkb | 213.32.76.112 is the newly held etherpad fwiw | 18:25 |
| clarkb | oh the swagger api is for api version 2 not 1 | 18:29 |
| clarkb | so I guess there is a new api but we're not using it (and testing should confirm old api keeps working) | 18:29 |
| clarkb | I think that is all fine | 18:29 |
| clarkb | /api-docs/ and /clarkb-test both seem happy to me from here | 18:30 |
| fungi | sort of annoying that both of these files have comments that indicate they're settings for the same thing, but their contents differ: https://github.com/maxking/docker-mailman/blob/main/postorius/mailman-web/settings.py https://github.com/maxking/docker-mailman/blob/main/web/mailman-web/settings.py | 18:37 |
| Clark[m] | Is that because web and postorius run as separate Django apps with separate settings in the same Django installation? | 18:40 |
| fungi | they do, but the docstring at the start of each of those files says "Django Settings for Mailman Suite (hyperkitty + postorius)" | 18:41 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Update Mailman containers to latest versions https://review.opendev.org/c/opendev/system-config/+/930236 | 19:11 |
| fungi | we'll see how that ^ fares in testing | 19:11 |
| fungi | clarkb: yep, held etherpad test node lgtm too | 19:23 |
| clarkb | cool. I've got to do the school run this afternoon but otherwise I am around. Shoudl we go ahead and approve it or wait for a better time? | 19:40 |
| fungi | i can't imagine a better time, i'll go ahead and approve it now | 19:40 |
| clarkb | the etherpad change should merge momentarily and the hourly jobs are already done | 20:28 |
| opendevreview | Merged opendev/system-config master: Update Etherpad to v2.2.5 https://review.opendev.org/c/opendev/system-config/+/930215 | 20:31 |
| clarkb | image has updated and it reports the container is healthy. | 20:35 |
| fungi | deploy jobs succeeded too | 20:35 |
| clarkb | etherpads I have open reload and look ok. I'll load up the meetpad isitbroken pad next | 20:36 |
| clarkb | seems to load there too | 20:36 |
| fungi | pulling up existing pads, they look fine and formatting is good | 20:36 |
| fungi | unrelated, the mailman upgrade change passed its rudimentary tests | 20:38 |
| clarkb | the swagger stuff loads too. Though I'm noticing it thinks it should talk to localhost:9000 so it probably needs to learn more about the proxy to be useful as an interactive api client | 20:40 |
| clarkb | not a big deal though as it works for api docs | 20:40 |
| opendevreview | Merged zuul/zuul-jobs master: Install doc bindep profile in zuul-jobs-test-tox https://review.opendev.org/c/zuul/zuul-jobs/+/929853 | 21:22 |
| opendevreview | Merged zuul/zuul-jobs master: Cleanup remaining Ansible lint warnings https://review.opendev.org/c/zuul/zuul-jobs/+/929828 | 21:29 |
| clarkb | fungi: in 921934 why do we need another site with another domain which means more certs etc when we already publish api specs to docs.openstack.org/api-ref? Could just do docs.openstack.org/openapi or similar? | 22:10 |
| clarkb | I've long been against the domain proliferation that openstack really loves to do | 22:10 |
| clarkb | it creates confusion over where to find things and disconnects related content | 22:10 |
| clarkb | anyway its on the meeting agenda so we can discuss there but I'm a soft -1 against a special domain for this. IMO it shoudl live next to the existing api ref content so that people can find it more easily | 22:11 |
| clarkb | (and we don't have to manage another set of resources that are difficult to cleanup in the future) | 22:11 |
| fungi | yeah, i wonder if there's a way to do that into a consistent parallel path, but part of the challenge is that the api specs are generated outside the projects themselves by another project | 22:12 |
| clarkb | ya I think you probably want to use /openapi/compute or whatever alongside /api-ref/compute | 22:12 |
| clarkb | then they won't publish over each other | 22:12 |
| fungi | and i think the idea is to be able to consume them in things like an ide or build them into language-specific sdks | 22:13 |
| clarkb | sure but I'm pretty sure those just need a url | 22:13 |
| clarkb | similar to how etherpad's swagger url is different than giteas | 22:13 |
| fungi | so having them all in a common tree rather than separated out to live alongside each project's docs would probably be simpler for those cases | 22:14 |
| clarkb | right I think I'm trying to say that is orthogonal | 22:14 |
| clarkb | whether or not you do that doesn't have any impact on whether or not we set up a new domain with new afs volume and new ssl certs | 22:14 |
| clarkb | (etherpad swagger is at /api-docs/ and giteas is at /api/swagger/ you just have to point tools as the appropriate endpoint) | 22:15 |
| fungi | well, sure, i mean also we could just have a dedicated apache vhost serve content from a subtree of the openstack docs tree too if the primary goal was just to have it at a portable base url | 22:15 |
| clarkb | I don't think you even need a separate vhost? | 22:16 |
| clarkb | I think you could just publish to openapi/ today right now without changing anything but zuul jobs? | 22:16 |
| fungi | if you want a dedicated subdomain you do | 22:16 |
| clarkb | right and I'm saying -1 to a subdomain | 22:16 |
| fungi | if you want to reuse the docs.openstack.org domain you don't | 22:16 |
| clarkb | because its mroe setup but more importantly its more teardown because removing things 10 years from now when openapi is no longer tool dejour is way more painful | 22:17 |
| fungi | i'm just saying whether the domain used is separate and whether the afs volume is separate are also each orthogonal to the other | 22:17 |
| clarkb | thats true, though there isn't a ton of reason to set up another volume if publishing to docs unless we expect the disk dmeands to diverage (and so will want to manage quotas separately) | 22:18 |
| fungi | in this case the use seemed more akin to the service-types.openstack.org content, which was set up with a dedicated domain for a reason, but maybe the reason isn't as compelling now as it was then | 22:19 |
| clarkb | fungi: I think the reason for that was it needed to be a well known single location? | 22:20 |
| clarkb | for public consumption | 22:20 |
| fungi | right, which would also be the case for public consumption of the api specs data | 22:20 |
| clarkb | I disagree bceause every cloud has a different api | 22:20 |
| clarkb | ultimately you're going to want to fetch the openapi data for the cloud you're talking to? | 22:21 |
| fungi | oh, well in this case i guess your disagreement is with the general idea of there being an official set of api specs for openstack | 22:21 |
| clarkb | similar again to how gitea ships swagger stuff for each deployment. YOu can still refer to the central document (I know I do because it pops up in google searches) but the one you really should care about is the one in the install you are speaking to | 22:21 |
| clarkb | ya I mean I think that ship sailed a long time ago unfortunately | 22:22 |
| fungi | the sdk team was proposing a central location for the openstack project to supply api specs for consumption by per-language sdk build processes and ide plugins | 22:22 |
| clarkb | right and that should be fine to live at docs.openstack.org? | 22:22 |
| fungi | and didn't consider this to be "documentation" but rather machine-consumed data | 22:22 |
| clarkb | the difference with the service types is that every time you start up a client you're referring to that data I (or at least checking if your cache needs refreshing) | 22:23 |
| clarkb | but that wouldn't be the case here. Instead whoever builds your sdk would simply need to know what the url is? | 22:23 |
| fungi | i think the idea was that an ide plugin would do that too. or an sdk build in ci | 22:23 |
| fungi | if memory serves, that's the design for the rust-based sdk: it consumes openapi specs to autogenerate the sdk source code | 22:24 |
| clarkb | ok I guess if others want to deal with the setup (and again more importantly imo the teardown when openapi is inevitably not cool aynmore) I won't stop anyone. I've just always been a proponent of pushing that type of thing into more central doc organized content bceause it makes it easier to find | 22:24 |
| clarkb | having things hosted under different domains gives indexers an implicit indicator that the content isn't directly related to content across domains | 22:25 |
| fungi | i had originally asked in the ptg session why just adding it to the api docs was insufficient, but there was resistance to expecting tooling to try dig the structured data out of the project docs | 22:25 |
| clarkb | the content doesn't have to live directly in structured docs though | 22:26 |
| clarkb | just hosted alongside it to make navigation easier and indexing associations | 22:26 |
| clarkb | I have made updates to the meeting agenda. Including moving the server upgrades item to the end | 22:43 |
| clarkb | but also added bits on dns over tls, the rocky package mirror, gitea upgrade | 22:44 |
| clarkb | does anything seem to be missing? | 22:44 |
| fungi | lgtm | 22:50 |
| clarkb | so I think a good chunk of my concerns would be alleviated if we made the domain less openapi specific. That way if openapi gets replaced we're not on the hook for doing a seamless migration and suddenly maintaining multiple domains for the same prupose | 22:52 |
| clarkb | that doesn't solve the problem of making things more difficult to find, but its definitely not the first time where people have disagreed with me on that and I can live with that | 22:52 |
| clarkb | https://github.com/terrastruct/d2 is a neat looking diagramming tool | 23:08 |
| clarkb | for the sequence diagrams in base-jobs docs (and I think in zuul too cc corvus) what do we think about maybe stashing the input file in docs/source/ but then manually generating the images when they change? | 23:09 |
| clarkb | the tool is MPLv2 licensed and is actively maintained. | 23:09 |
| clarkb | graphviz really doesn't do the sequence diagrams well unfortunately otherwise I'd just convert everything to that with the built in sphinx integration | 23:10 |
| corvus | yes, i believe i made those sequence diagrams | 23:10 |
| corvus | did the "get an ugly looking graphviz blob from blockdiag" approach not work out? | 23:11 |
| clarkb | corvus: we're currently generating them with blockdiag's sibling seqdiag. The problem is both blockdiag and seqdiag and their sphinx extensions are no longer maintained | 23:11 |
| corvus | yeah i know | 23:12 |
| clarkb | the alternative I was exploring was to use hacks like https://stackoverflow.com/questions/32436856/using-graphviz-to-create-tcp-flow-diagrams to have graphviz draw them. I haven't explored that further than reading that post | 23:12 |
| corvus | i mean you said that it looked like blockdiag used graphvis under the hood or something | 23:12 |
| clarkb | corvus: blockdiag uses the dot language under the hood but then I think is using Pillow to render things so graphviz isn't the backend they just share a markup language | 23:13 |
| clarkb | but also graphviz didn't accept the dot seqdiag was using so its some dialect that isn't directly compatible | 23:13 |
| corvus | oh got it. was hoping that running blockdiag to get a dotfile would give us a jumpstart on the stackoverflow approach | 23:14 |
| clarkb | I guess I can try the graphviz approach just to see how ugly it is | 23:15 |
| corvus | oh i think the graphviz output will probably be fine :) | 23:16 |
| corvus | clarkb: i have a moderate preference for translating this to graphviz; i am willing to help with that, but i can't work on it now. if this can wait a week or so i can probably help more. | 23:17 |
| corvus | honestly, if we can't graphviz, we should probably just consider ascii art | 23:18 |
| clarkb | ack I do think the stackoverflow example is a good starting point as it shows how to get the desired structure | 23:19 |
| clarkb | I'll fiddle with it and see if I can get something useable | 23:19 |
| corvus | (i feel like brining in a new toolchain that we never run because these images never change is probably more trouble than it's worth) | 23:19 |
| corvus | yeah, and i think the graphical output on the SO is fine | 23:19 |
| corvus | clarkb: thanks for digging into this :) | 23:21 |
| clarkb | I've got the tcp example building in the docs. Now to hack it up into something that resembles the container registry workflow and credit the SO example (does rst have comments?) | 23:22 |
| fungi | rst does have comments, yes | 23:54 |
| fungi | .. whatever | 23:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!