| opendevreview | Takashi Kajinami proposed opendev/system-config master: Update gpg key of puppetlabs repository https://review.opendev.org/c/opendev/system-config/+/854923 | 00:38 |
|---|---|---|
| *** lbragstad2 is now known as lbragstad | 01:04 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ansible-lint: pin to < 6.5 https://review.opendev.org/c/zuul/zuul-jobs/+/854335 | 01:08 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: linter: Use capitals for names https://review.opendev.org/c/zuul/zuul-jobs/+/854933 | 01:08 |
| *** dasm is now known as Guest1466 | 01:41 | |
| *** jpena|off is now known as jpena | 07:38 | |
| *** akahat_ is now known as akahat | 07:48 | |
| *** ysandeep is now known as ysandeep|lunch | 08:53 | |
| *** elodilles is now known as elodilles_pto | 09:26 | |
| *** pojadhav is now known as pojadhav|ruck | 09:30 | |
| * pojadhav|ruck afk for half hr | 09:33 | |
| *** rlandy_ is now known as rlandy | 10:31 | |
| *** ysandeep|lunch is now known as ysandeep | 11:02 | |
| *** dviroel_ is now known as dviroel | 11:31 | |
| opendevreview | daniel.pawlik proposed openstack/diskimage-builder master: Do not install python3-virtualenv in Centos 9 stream https://review.opendev.org/c/openstack/diskimage-builder/+/855014 | 11:35 |
| *** rlandy__ is now known as rlandy | 11:36 | |
| opendevreview | Merged opendev/system-config master: Update gpg key of puppetlabs repository https://review.opendev.org/c/opendev/system-config/+/854923 | 12:22 |
| *** dasm_ is now known as dasm | 14:03 | |
| opendevreview | Merged opendev/irc-meetings master: Restart of the Public Cloud SIG https://review.opendev.org/c/opendev/irc-meetings/+/853938 | 14:23 |
| clarkb | dpawlik: please see comments on 855014 | 14:40 |
| *** ysandeep is now known as ysandeep|out | 14:52 | |
| clarkb | fungi: I'm looking at https://release.debian.org/proposed-updates/stable.html to try and figure out when the updated glibc will end up in debian stable. Does that entire queue have to go green and then the entire set is updated in the debian repo together? | 14:58 |
| clarkb | (opendev will need to rebuild base python images when that lands so that zuul can drop its bookworm install of glibc) | 14:59 |
| *** dviroel is now known as dviroel|lunch | 15:08 | |
| fungi | clarkb: it's the "make grantpt usable after multi-threaded fork" part we're wanting, right? | 15:10 |
| fungi | spu just gets periodically "released" (every two months i think?) | 15:11 |
| clarkb | fungi: yes that is the fix we want and it is included in the queued package | 15:11 |
| fungi | 11.4 was releases on july 9, so i think we should expect 11.5 in a couple of weeks | 15:12 |
| fungi | er, was released | 15:12 |
| clarkb | I see, less of a queue and more of a set then | 15:13 |
| fungi | since the glibc update there is accepted in spu, it should be included in the next stable point | 15:13 |
| fungi | https://wiki.debian.org/DebianReleases/PointReleases says "about every two months" | 15:14 |
| *** pojadhav|ruck is now known as pojadhav|out | 15:15 | |
| fungi | that's part of why there's a separate security suite: it's an out of band way to provide critical fixes sooner than the spr cadence | 15:15 |
| clarkb | I'm half tempted to do a rebuild of our base python images anyway, but I think that can wait | 15:18 |
| fungi | it's also possible to add the spu suite in order to get packages from there in advance of the next spr | 15:19 |
| clarkb | Considering that the bookworm glibc is functioning I don't think that is necessary | 15:21 |
| fungi | clarkb: what was the workaround for "open /dev/pts/0: operation not permitted" trying to use docker-compose exec in the mailman-{core,web} containers? | 16:05 |
| *** dviroel|lunch is now known as dviroel | 16:07 | |
| frickler | use exec without "-t"? | 16:07 |
| frickler | just guessing from the issue I have in some other docker installations | 16:08 |
| frickler | that would be this one https://github.com/containerd/containerd/issues/7219 | 16:12 |
| Clark[m] | Yes run individual commands without the -t so no interactive session. | 16:12 |
| Clark[m] | I'm going to get a bike ride in now while the air outside is cool. | 16:13 |
| fungi | interesting. i'm not using -t but maybe there's something assuming -t | 16:15 |
| fungi | aha! "-T Disable pseudo-tty allocation. By default `docker-compose exec` allocates a TTY." | 16:16 |
| fungi | yep, that works | 16:17 |
| fungi | thanks! | 16:17 |
| *** jpena is now known as jpena|off | 16:31 | |
| frickler | seems containerd.io=1.6.8-1 got release on Friday, which contains the fix afaict | 16:37 |
| frickler | at least fixes it for my deployment | 16:38 |
| fungi | oh cool, thanks for the details | 16:39 |
| fungi | clarkb: i've used the steps noted at https://etherpad.opendev.org/p/mm3migration to import all three of our service-* mailing lists on the held 198.72.124.71 node and it seems to have worked, based on what browsing around i've done with my /etc/hosts overriding lists.opendev.org to that | 17:44 |
| fungi | note the list which is supposed to be private does indeed not allow anonymous archive browsing | 17:44 |
| fungi | (i checked that first to make sure i hadn't leaked any sensitive data) | 17:45 |
| fungi | clarkb: i added some comments in 851248 about things i ended up needing to tweak on the server in order to get it to work, all fairly trivial | 17:51 |
| fungi | for the moment i'm punting on the vhost config for serving the old pipermail archives, since that path will need to differ by domain name | 17:52 |
| fungi | i'm happy to push corresponding updates for that change if you agree with my comments | 17:53 |
| clarkb | fungi: repsonded. I think those edits are fine | 18:24 |
| clarkb | I left a suggestion for the file ownership stuff. I was really hoping upstraem would at least respond to my issue but we may need to decide if we are ok with things ebing weird with perms until they do or give up and build our own images based on theirs (that change /etc/passwd and chown things) | 18:25 |
| fungi | yeah, i'm good either way, i mainly just needed to do something so the process in the container could write to the index directory | 18:27 |
| *** Guest1238 is now known as diablo_rojo | 18:28 | |
| clarkb | ya I think if we just stop overriding the perms on that dir with ansible then the container does chown things itself | 18:28 |
| clarkb | fungi: you can also add a testinfra test to check that after both ansible runs complete | 18:28 |
| fungi | oh, good idea | 18:28 |
| clarkb | looks like the apt puppetlabs repo did end up getting synced after that change landed | 21:13 |
| opendevreview | Merged zuul/zuul-jobs master: ansible-lint: pin to < 6.5 https://review.opendev.org/c/zuul/zuul-jobs/+/854335 | 21:44 |
| *** rlandy is now known as rlandy|bbl | 21:59 | |
| clarkb | infra-root getting the meeting agenda together for tomorrow. Anything important missing? Maybe fedora 36? I guess I can add a note about the apt puppetlabs repo too | 22:01 |
| fungi | i didn't have anything in particular | 22:02 |
| ianw | me either, just things already in flight | 22:02 |
| clarkb | ok I'll add a fedora 36 topic so that I can get up to speed :) | 22:02 |
| clarkb | fungi: unrelated to the meeting agenda one thing I was hoping we could do with mm3 testing is have list creation set settings for lists to mimic our public lists from mm2 | 22:03 |
| clarkb | fungi: do you think that make ssense? Idea is that new lists we create would need less hand editing by their owners | 22:04 |
| clarkb | fungi: also if you create yourself an account on the test mm3 node does it automatically associate you with ownership on the migrated lists? | 22:04 |
| fungi | can you elaborate? i can't tell if you're asking for something which is already happening | 22:04 |
| fungi | and yes to the last one | 22:04 |
| fungi | oh, i see, you're asking about altering the default new list settings | 22:05 |
| fungi | not related to migration of existing lists (which does attempt to preserve them) | 22:05 |
| clarkb | fungi: when we create a list via ansible talking to the rest api we have the opportunity to set a bunch of list configuration settings. I think we should configure it so that new lists roughly match what we think a list should look like and we can use a migrated mm2 list as a short cut for that | 22:05 |
| clarkb | correct for new lists | 22:05 |
| clarkb | we should be able to query the api for a new list config and a migrated list config then determine if we should change any of those settings for new lists by default | 22:06 |
| fungi | yeah, i'll confess i don't know how different the mm3 defaults are from mm2's defaults, but we've in the past used the defaults when creating new lists and people rarely alter those | 22:06 |
| clarkb | the main things are going to be dmarc handling I think | 22:06 |
| fungi | if we change our stance on dmarc handling, perhaps. we've only adjusted a few lists for that | 22:07 |
| clarkb | fungi: ya and we consistenyl have peopl ebeing confused about it. I think we should stonrgly consider "sane" defaults for dmarc on new lists | 22:07 |
| fungi | and i have a feeling mm3 is going to be worse in regards to preserving messages on forward so that existing signatures still match | 22:07 |
| clarkb | oh? | 22:07 |
| fungi | as in, i wouldn't be surprised if we just need to turn on the dmarc mitigation features, as well as look into adding signing infrastructure for outgoing messages | 22:08 |
| clarkb | anyway I think it would be a good thing to compare are bare newly created list config to a migrated list config as a sanity check to see if there are any settings we want to automatically apply at list creation | 22:08 |
| clarkb | I'll make a note about it on the etherpad | 22:09 |
| fungi | but yeah, before we decide what our precise dmarc position is for mm3, we'll need to do some testing to see if it's enough like mm2 that we don't need to change our approach | 22:10 |
| clarkb | I'll poke at config comparisons tomorrow morning. You were going to update the change too right? We should probably make a new hold when we've got updated changes. Also I left some comments on the etherpad | 22:14 |
| fungi | yep, thanks! | 22:15 |
| fungi | clarkb: on the "Ensure Mailman volume directories exist" task, is there any reason not to just set them all to be owned by 100:101 like the containers expect? | 22:17 |
| clarkb | fungi: 100:101 on the host are used by other unrelated things. | 22:17 |
| fungi | right, i get that, but the end result is going to be that they're owned by 100:101 until the containers are fixed to not need that, right? | 22:18 |
| clarkb | fungi: I think the vast majority of the content doesn't need to be writeable. Would just be the indexes, the emails themselves (this may be an outstanding bug?) and the databse | 22:18 |
| clarkb | fungi: I think the container only does the subdirs. Also one container is 100:101 the other is 100:65543 or something | 22:18 |
| fungi | when i look at the content in all of those, it's owned by 100 | 22:18 |
| clarkb | that mismatch is part of why I'm trying to find a middle ground | 22:19 |
| fungi | and yeah, they're all either group mailman or group nobody | 22:19 |
| fungi | the core container seems to prefer group nobody while the web container uses group mailman | 22:19 |
| clarkb | ya its a bug (I filed it) | 22:19 |
| clarkb | at the very least they should be consistent imo | 22:19 |
| clarkb | fungi: I guess we can split that task up and make one half 100:101 and the other 100:nobody | 22:19 |
| fungi | right, what i guess i'm asking is, do we wait for the bug to be fixed, or do we set ansible to use the user:group mappings the containers expect for now with a big TODO comment? | 22:20 |
| clarkb | that would address potential bugs iwth mail writing (though I think everything happens in subdirs so it may just work) | 22:20 |
| clarkb | fungi: there is a third option which is that we build our own images and fix this issue iwth the images. We would update /etc/passwd and /etc/group and chown everything (and I think maybe need to edit their startup scripts too) | 22:21 |
| clarkb | But this is an open question to me right now. I'm not sure what the best thing to do is | 22:21 |
| clarkb | I think our options are: A) use 100:101/100:nobody in the appropriate dirs, B) inherit their images and modify them to match our host mailman user and group, C) build our own images from scratch (may be forks of their Dockerfiles though) | 22:22 |
| clarkb | fungi: maybe for continued testing work we can do A) with a TODO and we can dtermine later if we need to take the bigger step of making our own images | 22:23 |
| clarkb | then before we go to production make sure we've understood the impact of chowning everything later if sticking with A) | 22:24 |
| fungi | seems like we could do a easily for now until either they fix the problem or we're closer to production, then decide on b vs c once we know we need to do that additional work | 22:28 |
| clarkb | yup exactly | 22:28 |
| fungi | i'll add a todo in that part as well | 22:28 |
| clarkb | fungi: maybe add a link to the issue I filed in the TODO? | 22:34 |
| fungi | oh, yes great idea | 22:34 |
| *** dviroel is now known as dviroel|out | 22:42 | |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: WIP Add a mailman3 list server https://review.opendev.org/c/opendev/system-config/+/851248 | 23:10 |
| fungi | clarkb: ^ also i edited the pad to reflect your fqdn directory idea | 23:13 |
| clarkb | fungi: oh cool. Otherwise we'd need some sort of table lookup to keep the redirects all in one vhost | 23:18 |
| fungi | yes. since there's a known number of domains and migration is a one-time thing, i think we can just do the "mapping" manually when copying the data to the server so that the thing we're maintaining going forward is simpler | 23:18 |
| clarkb | ++ | 23:20 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Match the ansible-lint <6.5 pin from zuul-jobs https://review.opendev.org/c/openstack/project-config/+/855098 | 23:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!