opendevreview | Jeremy Stanley proposed opendev/system-config master: Restart Mailman 3 containers when configs change https://review.opendev.org/c/opendev/system-config/+/891555 | 00:12 |
---|---|---|
fungi | Clark[m]: like that? ^ | 00:13 |
Clark[m] | fungi: you need to replace the uwsgi check with a mailman service check if appropriate | 00:14 |
Clark[m] | Or is it uwsgi that mailman runs? | 00:14 |
fungi | yes | 00:14 |
fungi | django is running from uwsgi | 00:15 |
Clark[m] | Ah ok. I guess in my head Django has it's own thing but I guess not | 00:15 |
fungi | i figured it was the easiest thing to check for | 00:15 |
fungi | rather than arbitrary python processes for queue runners | 00:15 |
Clark[m] | But I don't think it will trigger that task to list the uwsgi stuff it will only trigger your restart task use to the name you notify | 00:16 |
fungi | i think django has its own inbuilt server as an option, but the deployment uses uwsgi | 00:16 |
fungi | how does the one for jitsi know to run the similar check it has? | 00:17 |
fungi | playbooks/roles/letsencrypt-create-certs/handlers/restart_graphite.yaml also has a similar one | 00:18 |
Clark[m] | It uses include tasks to run all the tasks in the included file when triggered here https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/letsencrypt-create-certs/handlers/main.yaml#L45 | 00:18 |
Clark[m] | So the name on like 44 there is what you notify them when it runs it runs everything in the included task file | 00:19 |
fungi | aha | 00:19 |
fungi | so probably can't put those in the same handler file as the apache reload/restart | 00:19 |
Clark[m] | Correct | 00:23 |
fungi | so how do i make sure it runs only once regardless of how many config files change, and only if the containers are already running? | 00:27 |
Clark[m] | That is what Ansible handlers do. They only run once at the end | 00:42 |
Clark[m] | So you notify the top level handler. It includes the multiple tasks and they run but only once | 00:42 |
fungi | er, so the file itself is the top-level handler? | 00:50 |
Clark[m] | The handlers/main.yaml is where your top level goes. This is the one whose name you notify. That single task can then include tasks from another adjacent file just like the LE example which does all the steps you need in multiple tasks | 00:53 |
fungi | oh, got it | 00:54 |
opendevreview | Jeremy Stanley proposed opendev/system-config master: Restart Mailman 3 containers when configs change https://review.opendev.org/c/opendev/system-config/+/891555 | 01:00 |
fungi | okay, so that i guess ^ | 01:00 |
Clark[m] | Ya that looks correct. I'll take a closer look in the morning | 01:02 |
fungi | thanks! | 01:03 |
*** dmellado819181 is now known as dmellado81918 | 04:45 | |
opendevreview | Md Irshad Sheikh proposed openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 07:16 |
opendevreview | Md Irshad Sheikh proposed openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 07:19 |
opendevreview | Md Irshad Sheikh proposed openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 07:34 |
opendevreview | Md Irshad Sheikh proposed openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 07:44 |
opendevreview | Md Irshad Sheikh proposed openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 08:42 |
opendevreview | Dmitriy Rabotyagov proposed openstack/diskimage-builder master: Set platform argument in container build command for cross-arch builds https://review.opendev.org/c/openstack/diskimage-builder/+/884451 | 10:00 |
opendevreview | Jeremy Stanley proposed opendev/system-config master: Restart Mailman 3 containers when configs change https://review.opendev.org/c/opendev/system-config/+/891555 | 11:56 |
fungi | anyone up for reviewing a minor git-review fix as a break the monotony and/or excitement of their day? https://review.opendev.org/890043 | 12:04 |
*** jroll8 is now known as jroll | 12:09 | |
frickler | fungi: that sounds interesting enough to make me have a look ;) | 12:23 |
* frickler offers a boring https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146 in return | 12:24 | |
fungi | ooh, don't mind if i do | 12:24 |
frickler | " | 12:25 |
frickler | "Tisza Gergő created this story on 2012-07-12 at 19:54:03 " wow | 12:25 |
fungi | i forgot we had a storyboard deployment that long ago | 12:30 |
fungi | that was basically right when i got involved in openstack | 12:30 |
fungi | oh! that's an import from launchpad | 12:31 |
fungi | bug number should match | 12:31 |
fungi | yep https://bugs.launchpad.net/git-review/+bug/1024054 | 12:31 |
opendevreview | Jeremy Stanley proposed opendev/git-review master: Use GIT_SSH for the SSH executable https://review.opendev.org/c/opendev/git-review/+/890043 | 12:59 |
fungi | frickler: ^ does that suit you? | 13:00 |
fungi | reduced the entire change to just one line, since there was only one place that new variable was getting used anyway | 13:02 |
fungi | making a separate assignment just for that seemed unnecessary | 13:02 |
frickler | fungi: ah, one step further even than my proposal, ack | 13:03 |
*** blarnath is now known as d34dh0r53 | 13:31 | |
opendevreview | Merged openstack/project-config master: Add Intel Device Plugins app to StarlingX https://review.opendev.org/c/openstack/project-config/+/891566 | 14:29 |
opendevreview | Merged opendev/git-review master: Use GIT_SSH for the SSH executable https://review.opendev.org/c/opendev/git-review/+/890043 | 14:57 |
clarkb | fungi: left a small concern on the mm3 notify change | 15:41 |
clarkb | also I think I'm mostly awake now if we want to approve the etherpad upgrade change | 15:41 |
fungi | cool, i'm ready when you are | 15:42 |
fungi | want me to approve that one? | 15:42 |
fungi | also i agree with your comment on the mm3 change, i was parroting what the grafana/jitsi cert update tasks do, but they're just restarting containerized web servers | 15:43 |
clarkb | fungi: sure go for the approval | 15:43 |
fungi | i'll fix that | 15:43 |
clarkb | by the time it actually lands I should have had something to eat and loaded my ssh keys :) | 15:44 |
opendevreview | Clark Boylan proposed opendev/system-config master: Update to Gitea 1.20 https://review.opendev.org/c/opendev/system-config/+/886993 | 15:53 |
opendevreview | Jeremy Stanley proposed opendev/system-config master: Restart Mailman 3 containers when configs change https://review.opendev.org/c/opendev/system-config/+/891555 | 16:22 |
fungi | clarkb: is it safe enough to just do that ^ or does the first task need to to register a result that the second requires? | 16:23 |
clarkb | fungi: if the down fails then the ansible run should stop there and not up the system which is probably what we want? | 16:23 |
fungi | yes, okay i wasn't sure if it would try to run the second task regardless | 16:24 |
clarkb | the first task looking for uwsgi processes needs the ignore errors flag set to true because we expect it to occasionally exit non zero | 16:25 |
clarkb | I guess one downside to this approach is that we're doing a docker-compose up -d here https://review.opendev.org/c/opendev/system-config/+/891555/4/playbooks/roles/mailman3/tasks/main.yaml#136 so we may restart twice | 16:26 |
fungi | aha, so the absence of "ignore_errors: yes" in "down containers" means that if it fails then "up containers" will get skipped | 16:26 |
clarkb | I think that is ok for bootstrapping and actually that may make the restart later fine | 16:26 |
clarkb | so maybe we didn't need to rewrite the last patchset... | 16:27 |
opendevreview | Merged openstack/project-config master: Allow neutron-core to act as osc/sdk service-core https://review.opendev.org/c/openstack/project-config/+/890914 | 16:27 |
opendevreview | Merged openstack/project-config master: Remove ocata related definitions https://review.opendev.org/c/openstack/project-config/+/825372 | 16:27 |
clarkb | up -d will restart things if new container images are present otherwise it is a noop | 16:28 |
clarkb | and we have to up things there in the playbook because we need to check db state for bootstrapping steps so we can't move everything back into the handler at the end | 16:28 |
clarkb | so ya maybe the restart would be fine? I think both approaches are ok I guess just occasionalyl we'll do a restart too many | 16:29 |
opendevreview | Merged opendev/system-config master: Update etherpad to 1.9.1 https://review.opendev.org/c/opendev/system-config/+/887006 | 16:29 |
fungi | i'm not following... should i replace the "Run docker-compose up" task with a notify to the restart handler instead? | 16:29 |
opendevreview | Merged openstack/project-config master: Remove publish-install-guide ocata job https://review.opendev.org/c/openstack/project-config/+/825374 | 16:29 |
fungi | though we have subsequent tasks that rely on the container being up, so the handler may run too late if we did that | 16:30 |
clarkb | fungi: no you shouldn't do that for the reason I stated above. We need the processes up and running so that all the bootstrapping stuff here https://review.opendev.org/c/opendev/system-config/+/891555/4/playbooks/roles/mailman3/tasks/main.yaml#183 can run | 16:30 |
clarkb | basically we cannot get away with a simple down/up -d in the handler as that occurs too late | 16:30 |
fungi | okay, so basically what's going to happen is that tasks/main.yaml bootstraps the server and starts the container, but then the notify will result in downing and upping the container again at the very end? | 16:31 |
clarkb | yes | 16:31 |
clarkb | and it might be worth thinking about the ramifications of that a bit before we land the change | 16:31 |
fungi | and that's presumably not only safe but could also serve as a good test that things are restarting correctly | 16:31 |
clarkb | ya. It will just result in the occasionally longer than necessary outage | 16:33 |
clarkb | etherpad has updated | 16:40 |
clarkb | yesterday's etherpad for zuul fixups loads for me https://etherpad.opendev.org/p/d0l2F7iYeyHzVw1EpSBy | 16:40 |
clarkb | as far as I can tell it is working | 16:41 |
clarkb | keep an eye out for problems but my first impressions is that this is working as expected | 16:44 |
fungi | lgtm too, yep | 16:51 |
fungi | worth noting, that indentationOnNewLine default doesn't seem to actually do anything | 16:53 |
fungi | it still indented after a : | 16:53 |
clarkb | fungi: also possible the example file is not showing defaults but an opinionated config which would be weird but possible | 16:54 |
fungi | ohhh | 16:54 |
clarkb | we could try explicitly setting it to the value we want in our own config | 16:54 |
fungi | yeah, could be | 16:54 |
fungi | well, it would be a behavior change, so i'm not sure the disruption is warranted | 16:55 |
clarkb | our backspace keys can get more exercise | 16:55 |
fungi | people are used to deleting the extra spaces at the start of the next line if they didn't want it | 16:55 |
clarkb | fungi: idea: we could register the output of the first docker-compose up -d maybe and check that in the handler | 17:07 |
clarkb | if the first one actually started everything we can skip the handler restart? | 17:08 |
clarkb | possible that is too fragile to bother with though | 17:08 |
fungi | is it possible to register that in the tasks and then check it in the handler? | 17:09 |
fungi | if so, i'm cool with it, doesn't seem especially fragile | 17:10 |
clarkb | yes I think so. The fragility would be with the output of docker-compose being consistent and parseable. I think we do this elsewhere somewhere already though | 17:11 |
clarkb | but I can't remember where | 17:11 |
fungi | can't just check the exit code? | 17:11 |
clarkb | No because I ran and didn't restart anything because everything is up to date is exit code zero 0 iirc | 17:12 |
fungi | mmm | 17:12 |
clarkb | docker-compose up -d will stop and create new containers if new images are available. It will also take action if no containers are running | 17:12 |
clarkb | But it can also say "no work to do" and noop | 17:12 |
clarkb | its the no work to do and noop case that we want the handler to run | 17:12 |
fungi | yeah, i can see where that would lead to issues | 17:13 |
clarkb | ok that last gitea patchset fixed the access logs. Ithink we're very close to being ready with to land that as long as we accept we have to add a bunch of config for oauth which we disable... | 17:52 |
clarkb | I'm going to get a node held and we can decide if we are comfortable with that after reviewing a running server | 17:52 |
opendevreview | Clark Boylan proposed opendev/system-config master: DNM intentional gitea failure to hold a node https://review.opendev.org/c/opendev/system-config/+/848181 | 17:53 |
fungi | infra-root: ildikov directly sent me a specific list of matrix space and channel names the starlingx community has requested we add to our homeserver, so in keeping with the consensus we reached in our meeting i'm proceeding to set those up now | 19:01 |
clarkb | wfm | 19:12 |
fungi | anybody happen to know if there's a lag when setting icons for matrix channels? as opendev.org homeserver admin i added the starlingx logo as the icon for their space and each of their channels and i see it in the tab i have logged in for that account, but when i join them from my personal account i just see the letter "s" | 19:26 |
frickler | what's the space name? I can double-check with my non-matrix.org acc | 19:28 |
clarkb | I don't know | 19:28 |
fungi | https://matrix.to/#/#starlingx:opendev.org | 19:28 |
fungi | should be a purple x-like icon if it's loading correctly | 19:29 |
fungi | also, do we need to use the admin account to set channel descriptions, or is that something which can be delegated to the project? | 19:30 |
frickler | I can confirm that I only see a green "S". for our downstream space there is an icon, but the person who set that up is on PTO | 19:31 |
fungi | as for the icon, i definitely see icons for other channels we have, e.g. #zuul, so it could just be something that doesn't propagate straight away | 19:31 |
fungi | corvus: ^ also possible you remember whether there were any special steps when you added a logo icon for the zuul channel | 19:36 |
fungi | maybe accounts on other homeservers have to wait for icons to replicate across the federated network | 19:36 |
clarkb | fungi: I don't think we've delegated any permissions for zuul. So the admin account has to do it all currently | 19:39 |
fungi | sure, the question was more whether such delegation is possible | 19:44 |
clarkb | it is possible | 19:44 |
ildikov | fungi: Thank you! The space looks great overall. Can you also create a 'StarlingX General' room in addition to the project team rooms? I think that's the only one that seems to be missing. | 19:45 |
clarkb | fungi: in element if you open the people panel on the right side and hover on users admin is power:100 and regular users are power:0 | 19:45 |
clarkb | you can asign power values to people which allow them to do more stuff. I'm not sure what specific value is needed for topic setting though | 19:45 |
fungi | ildikov: oops, thanks i missed that because it was in a different section of your list all by itself. adding it now! | 19:46 |
fungi | clarkb: aha, thanks, so "power users" is matrix's approximation for irc channel operators? | 19:46 |
clarkb | looks like users can give other users power up to their power level (very dragon ball z like all of a sudden) | 19:46 |
clarkb | fungi: its a 0-100 scale | 19:46 |
fungi | neat | 19:46 |
clarkb | so more nuanced than irc | 19:46 |
clarkb | sounds like normal user is typically 0, moderator is 50, and admin is 100 for channels though that may partly be by convention | 19:47 |
fungi | ildikov: it's added now | 19:48 |
ildikov | fungi: awesome, thank you! | 19:48 |
clarkb | looks like the recommendation for the fedora community is that admin be a very small group (we alredy do this). Then the majority of people who need extra perms get power:50 moderator power. THen you configure the rooms to let moderators do things like set topic | 19:48 |
clarkb | with zuul we've kept it simple though and it has been working fine | 19:48 |
fungi | clarkb: i guess then it's a matter of figuring out what "power level" is required for things like channel description/topic | 19:48 |
clarkb | fungi: yes, though it sounds like you configure that as admin and by default it is proabably requiring power level 100 | 19:49 |
clarkb | but you'd find those options and set them to 50 and promote a small number of moderators to power level 50 | 19:49 |
fungi | makes sense. i was going to see if i could work out how to give ildikov the ability to set the descriptions for these initial 11 channels since i lack the context to come up with them on my own | 19:50 |
fungi | aha, there's a "roles and permissions" in the space settings | 19:50 |
clarkb | oh so you can do it at a top level for all space rooms at once? | 19:51 |
clarkb | thats a nice efficiency thing | 19:51 |
fungi | i'll find out i suppose. it may be that the channels don't inherit roles from the space and have to be set individually | 19:51 |
clarkb | https://104.239.143.111:3081/opendev/system-config gitea 1.20.2 running via our config mangaement | 19:51 |
ildikov | yeah, I was looking for something like 'moderator' level, or smth that allows me to take care of the StarlingX space | 19:52 |
ildikov | so I don't need to bug y'all with every little nuance | 19:52 |
fungi | ildikov: ironically, it's called "moderator" even ;) | 19:52 |
clarkb | The theme color thing I did for mobile isn't working. However it seems to not work with the existing deployment on 1.19 either. I wonder if that is a dark vs light theme thing overriding our color | 19:52 |
ildikov | yeah, I was influenced by the convo here ;) | 19:52 |
clarkb | aha yup that is the issue. If I hardset theme to light in my mobile browser both the test node and production gitea use the pink color theme | 19:53 |
fungi | there is a named power level called "moderator" and by default it has the roles: change settings, remove users, ban users, change space name, change main address for the space, change space avatar, manage rooms in this space, change description | 19:54 |
clarkb | hrm but maybe that was sticky from opendev.org. Retrying with the test node doesn't make it pink | 19:54 |
clarkb | fungi: I would remove change main address for the space at least | 19:55 |
fungi | additionally it gets the "invite users" role which the default power level has (so everyone can do it) | 19:55 |
ildikov | fungi: that sounds like a reasonable list of things! | 19:55 |
clarkb | but otherwise those seem reasonable for a trusted group of moderators | 19:55 |
fungi | the one role moderator lacks is "change permissions" (which only the admin power level has) | 19:55 |
ildikov | I think that's fine | 19:56 |
fungi | and yeah, it does seem like the ability to change the main address is a bit of a foot cannon | 19:56 |
clarkb | fungi: ya so moderator cannot give themselves new permissions | 19:56 |
clarkb | which seems correct | 19:56 |
clarkb | but also it seems like those are space specific and not room inheritable perms? | 19:57 |
clarkb | I guess that makes sense since arbitrary rooms can be added to arbitrary spaces | 19:57 |
fungi | so if i open the settings for a specific room there are more roles | 19:57 |
fungi | default power level: send messages, send reactions, remove messages sent by me | 19:58 |
fungi | moderator power level: invite users, change settings, remove users, ban users, remove messages sent by others, notify everyone, change room name, change main address for the room, change room avatar, change topic, send m.room.pinned_events events, send org.matrix.msc3401.call events, send org.matrix.msc3401.call.member events, modify widgets, voice broadcasts | 20:00 |
clarkb | side note if you add the channel recording bot it will record deleted messages forever | 20:00 |
fungi | admin power level: change permissions, change history visibility, upgrade the room, change server acls, enable room encryption | 20:00 |
clarkb | fungi: I think changing the main address for the room should be removed, but otherwise those seems reasonable | 20:00 |
clarkb | for moderator I mean | 20:01 |
fungi | okay, i figured out where to get at the top-level settings panel for the homeserver too | 20:01 |
corvus | fungi: i think the avatar was just a moderator-level setting on the room | 20:02 |
fungi | seeing if there's somewhere to set the default role profile server-wide | 20:02 |
fungi | corvus: yeah, setting the avatar is, i'm wondering if i'm seeing a propagation delay for avatars between homeservers | 20:02 |
corvus | fungi: be careful of the format; i think it may silently ignore nonconforming images | 20:03 |
fungi | oh, good to know. it showed up for me on the admin account for the homeserver but not for my account on another homeserver, so maybe it won't replicate if it's not in the right format? | 20:03 |
fungi | hmm, what i thought was the top-level settings for the homeserver was actually just the personal settings for the admin account's client session. i don't see anywhere obvious we can set a default inheritance for permission levels. i think if we want to make "change address" unavailable to moderators then we have to do that one at a time on every channel | 20:07 |
clarkb | :( | 20:08 |
clarkb | in my head changing an address should almost never happen. If you want a new channel make a new channel. So giving that permission to anone but admins seems wrong | 20:08 |
corvus | keep in mind that an address is just a pointer, so even if (very hypothetically) the starlingx mods go rogue and defect from the community and change the room's main address, the #starlingx-whatever:opendev.org address should still exist and work | 20:10 |
corvus | (i still think it's something that is in appropriate for mod-level perms in our community; but it sort of makes sense from a decentralized system standpoint) | 20:11 |
corvus | fungi: i'm not at the moment sure what the image format is supposed to be. but i also don't see it (unless i click on the "S" and then it does pop up). | 20:12 |
fungi | okay, i think i got "change main address" delegation set to admin instead of moderator in all 11 of the initial starlingx rooms and the space. we'll just want to remember to add that for any other channels that are added | 20:12 |
fungi | corvus: yeah it's weird, with the opendev.org homeserver admin account logged in with the element browser client, it shows the avatar i set in the left sidebar for every channel, but not when joining them from my matrix.org account | 20:13 |
corvus | fungi: i believe i used pngs, and i think maybe you used an svg? | 20:13 |
fungi | oho, so it was | 20:13 |
frickler | that seems to be an svg icon? pretty sure you'll want some scaled down png or jpg | 20:13 |
frickler | or what corvus says ;) | 20:14 |
fungi | i'll try to swap it out for another format. thanks for spotting | 20:14 |
corvus | if i'm looking at the right thing, i think the zuul logo may be 120x120 png | 20:17 |
corvus | i have another room logo that's 512 square though | 20:18 |
fungi | well, when i preview the space, element helpfully converted it to a 96x96 pixel png | 20:23 |
fungi | (from svg), so maybe that's a sign that there's no need to make it any bigger | 20:23 |
clarkb | I think bigger pngs will do better on higher resolution displays | 20:29 |
clarkb | assuming you aren't already in mac display territory on your system | 20:29 |
fungi | no matter how much border i try to put around the logo, matrix still wants to crop it and round the corners. maybe i need to embed a subtle border | 20:40 |
fungi | er, it crops away the padding i mean | 20:40 |
fungi | never mind, pebcak: was missing that i needed to click the "save" button in the settings | 20:51 |
clarkb | I can see the meta theme-color information in my browser so my template overriding is working | 20:53 |
clarkb | stackoverflow says " | 20:53 |
clarkb | chrome requires you to have a valid certificate for the theme-bar color to work | 20:53 |
clarkb | so maybe we just send it when we are ready and hope it works? | 20:53 |
clarkb | and if not its a super minor thing anyway that doesn't work by default on my dark theme phone setup | 20:53 |
fungi | corvus: frickler: thanks! switching to png got everything working | 20:54 |
corvus | looks good from here too! | 20:56 |
fungi | ildikov: i've made you a moderator for the space itself, but i expect i'll need to still set you as a moderator individually in each room, and i'm not sure how to do that unless you join all 11 of those channels first | 20:57 |
clarkb | I see them in the public room listing for opendev.org with logos | 20:57 |
fungi | ildikov: but once you're a moderator, i think you should be able to set others as moderators too (or if you can't yet i think we can configure that option) | 20:58 |
clarkb | fungi: I think anyone can set anyone else to the same powerlevel or lower than themselves | 20:58 |
fungi | i need to take a break and cook dinner, but will get back to this once eating has concluded | 20:59 |
clarkb | fungi: it looks like docker-compose echos 'foo-container is up-to-date' for every container that it noops on when running up -d | 22:03 |
clarkb | fungi: I think this means we can check for 'is up-to-date' in the stdout of the up -d command and if that is present then restart things. Otherwise we know that all the containers were either just started for the first time or were all restarted for updates | 22:04 |
clarkb | I think that is the most correct thing to avoid unnecessary downtime one after another when updating both configs and container images at the same time | 22:04 |
clarkb | I tested this on jvb01 because we keep those up to date and restarting them should it restart has minimal impact | 22:05 |
clarkb | if you want to confirm just cd into that dir (remember it has env files so you have to be in that dir) then run docker-compose up -d | 22:05 |
fungi | well, there's also a d-c option to give the path to the env file, so technically not necessary to cd | 22:07 |
ildikov | fungi: sorry, I was on calls. I joined all the rooms now, and I will need someone to set moderator right for me there too | 22:10 |
ildikov | Everything else looks great! | 22:10 |
ildikov | I can see the logo populated not too, which is nice | 22:11 |
fungi | ildikov: no worries, just saw you arrive and have started to set you to a mod | 22:11 |
ildikov | Perfect, thank you so much! | 22:11 |
ildikov | s/not/now/ | 22:11 |
fungi | ildikov: looks like it says you're a mod now in the space and also all 11 initial rooms | 22:13 |
fungi | and yeah, it looks like there's no way to set someone as a moderator in a room until they join that room, which is why it had to wait | 22:13 |
fungi | and also, moderator level isn't inherited from the space itself, so has to be done independently for each room | 22:14 |
ildikov | Yep, I can confirm all that | 22:14 |
ildikov | I will set topics, etc and then update the StarlingX ML about the new setup | 22:15 |
fungi | sounds great. let me know if you run into any other gotchas | 22:15 |
ildikov | Will do, thank you! | 22:16 |
fungi | any time | 22:16 |
opendevreview | Jeremy Stanley proposed opendev/system-config master: Restart Mailman 3 containers when configs change https://review.opendev.org/c/opendev/system-config/+/891555 | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!