*** dhill is now known as Guest13464 | 12:27 | |
corvus | it looks like the zuul-launcher vhd images for rax-classic built, and launcher attempted an upload but | 14:19 |
---|---|---|
corvus | 2025-04-10 02:43:30,402 DEBUG zuul.openstack.rax-DFW: API call create_image in 546.6630557299941 | 14:19 |
corvus | 2025-04-10 02:43:30,402 ERROR zuul.Launcher: openstack.exceptions.ResourceTimeout: Timeout waiting for Task:bb7c1a7d-bb30-4033-a8c0-41637802c8fd to transition to success | 14:19 |
corvus | and then later followed by | 14:21 |
corvus | 2025-04-10 05:06:55,575 ERROR zuul.Launcher: openstack.exceptions.DuplicateResource: More than one Image exists with the name 'debian-bullseye-f13f90eedc8447c98b9ac9ec47d721ff'. | 14:21 |
corvus | (after it retried) | 14:22 |
frickler | iirc we needed to bump the timeout in nodepool in order to resolve a similar issue? how long is it for z-l? | 14:23 |
corvus | that log makes it look like it's maybe about 10m ... not sure why it ended up with 546 seconds though... | 14:25 |
corvus | okay, yeah, there are two weird things: | 14:26 |
corvus | 1) the timeout in zl is hardcoded to 300s because that's a TODO item, so that's obviously the thing we need to fix. | 14:26 |
corvus | 2) 300s is a lot less than the 546 seconds it actually took for openstacksdk to timeout. :) | 14:27 |
corvus | i will fix #1 and not address #2 other than to just to now know that's a quirk of sdk | 14:27 |
fungi | it looks like we set `image-upload-timeout: 21600` (6 hours) on all our providers in nodepool, that's almost certainly overkill | 14:36 |
fungi | but also a lot more than 300 | 14:36 |
corvus | https://review.opendev.org/947006 should let us set it | 14:43 |
opendevreview | Merged zuul/zuul-jobs master: Add eatmydata support to ensure-zookeeper https://review.opendev.org/c/zuul/zuul-jobs/+/946289 | 14:46 |
clarkb | corvus: the other thing to keep in mind is rax uses the two phase upload | 14:46 |
clarkb | corvus: that may explain why the timeout was longer maybe? (first upload is to swift and second is the glance task that imports from swift) | 14:46 |
corvus | yeah, i think that's working as expected based on the errors.. ah good point, so the timeout may have been applied to each of those individually or one of those (but maybe not both together) | 14:47 |
corvus | that would explain curiosity #2 | 14:47 |
clarkb | ya I can't say for sure but I wouldn't be surprised if that plays into the odd timeout length | 14:48 |
clarkb | infra-root I believe that review03 backups failed because mariadb is not running yet | 14:50 |
clarkb | one of the things I'll try to do today after the ptg is start the mariadb and put the 02 data into it | 14:50 |
clarkb | that should make those errors go away | 14:50 |
opendevreview | Clark Boylan proposed opendev/system-config master: Publish hound container images to quay https://review.opendev.org/c/opendev/system-config/+/947010 | 15:07 |
clarkb | that is something I realized we could do now and slightly reduce our reliance on docker hub a bit more | 15:08 |
opendevreview | Clark Boylan proposed opendev/system-config master: Publish hound container images to quay https://review.opendev.org/c/opendev/system-config/+/947010 | 15:17 |
dan_with | Hello. The weekend is nearly upon us. I had some alerts come in today. I believe this is alert would have popped a long time ago, but we have been working out issues with new alerting. This is the proposed fix: | 15:28 |
dan_with | SJC: | 15:28 |
dan_with | 1. YOU: Take 5e5f88e8-0c40-4383-ba0a-5d7017640b99 (mirror02.sjc3.raxflex.opendev.org) out-of-rotation | 15:28 |
dan_with | 2. YOU: Shutdown | 15:28 |
dan_with | 3. YOU: Detach volume: dbe8649d-b093-44c3-9b42-50fd49f882a0 (mirror02.sjc3.raxflex.opendev.org/main01) | 15:28 |
dan_with | 4. ME: Quick cleanup command on hypervisor. I'll let you know when complete. | 15:28 |
dan_with | 5. YOU: Reattach volume to instance | 15:28 |
dan_with | 6. YOU: Boot 5e5f88e8-0c40-4383-ba0a-5d7017640b99 (mirror02.sjc3.raxflex.opendev.org) | 15:28 |
dan_with | Would this be something we can do today? | 15:28 |
clarkb | I'm trying to remember is this the same mirror we already do that to or was that dfw3 and now we're repeating in sjc3? | 15:29 |
clarkb | anyway we can start on that now | 15:29 |
opendevreview | Clark Boylan proposed openstack/project-config master: Set rax flex sjc3 max-servers to 0 for mirror work https://review.opendev.org/c/openstack/project-config/+/947015 | 15:31 |
opendevreview | Clark Boylan proposed openstack/project-config master: Revert "Set rax flex sjc3 max-servers to 0 for mirror work" https://review.opendev.org/c/openstack/project-config/+/947016 | 15:31 |
dan_with | Similar problem, but different env. I think this happened because Opendev was an early adopter. I want to make sure that this doesn't come back to bite us at some point in the future. | 15:32 |
clarkb | ack I need one more change up I'm working on then we can land the things that disable usage and then proceeed | 15:34 |
dan_with | ack, thank you | 15:34 |
opendevreview | Clark Boylan proposed opendev/zuul-providers master: Temporarily disable rax flex sjc3 https://review.opendev.org/c/opendev/zuul-providers/+/947017 | 15:35 |
opendevreview | Clark Boylan proposed opendev/zuul-providers master: Revert "Temporarily disable rax flex sjc3" https://review.opendev.org/c/opendev/zuul-providers/+/947018 | 15:35 |
clarkb | infra-root corvus ^ I'll self approve 947015 and 947017 in a few minutes if no one beats me to it | 15:35 |
opendevreview | Merged opendev/zuul-providers master: Temporarily disable rax flex sjc3 https://review.opendev.org/c/opendev/zuul-providers/+/947017 | 15:36 |
corvus | i did beat you to it | 15:36 |
clarkb | thanks! | 15:36 |
timburke | clarkb, sorry i didn't see your question yesterday, but yeah, epoxy was the first swift release without py2 testing. now technically, we'd already declared yoga to be the last stable branch to support py2 -- but reality has this way of getting in the way of a plan | 15:42 |
timburke | but it also means we no longer need to worry about ensuring py2 compatibility for our open stable branches | 15:42 |
opendevreview | Merged openstack/project-config master: Set rax flex sjc3 max-servers to 0 for mirror work https://review.opendev.org/c/openstack/project-config/+/947015 | 15:42 |
corvus | https://grafana.opendev.org/d/6d29645669/nodepool3a-rackspace-flex?orgId=1&from=now-6h&to=now&timezone=utc&var-region=raxflex-sjc3&refresh=1m | 15:44 |
clarkb | timburke: cool I think that was one of the major milestones we were waiting on before PBR can even consider what python2 support removal looks like | 15:44 |
clarkb | I think it is probably still a bit early to immediately remove python2 support from pbr, but now we can start planning it knowing the last major user of it is done | 15:44 |
clarkb | corvus: the deploy job us running now. That graph should update shortly I hope | 15:45 |
clarkb | infra-root https://etherpad.opendev.org/p/O4aG1FCUb3o72NHRc0jQ started drafting a gerrit outage for the server move/upgrade next week in this doc | 15:45 |
timburke | if it'd help, i can propose backports of https://review.opendev.org/c/openstack/swift/+/853590 to the open stable branches | 15:45 |
clarkb | let me know if you think any important info is missing or if that block at the end is not useful | 15:45 |
corvus | depending on how antsy we are, we could wait for that to drop to 0, or we could probably start like 10m after it deploys. | 15:46 |
clarkb | timburke: ya I think we need open stable branches to drop support too. But I think at least for now we're not in a rush | 15:46 |
clarkb | timburke: its just that maybe in a year or two it will be possible :) | 15:46 |
clarkb | corvus: there are no release pipeline jobs running so 10 minute delay then call it good is probably fine | 15:48 |
clarkb | and our 10 minutes starts now | 15:48 |
clarkb | the graph just dropped to 0 | 15:48 |
clarkb | ok 10 minutes are up. I guess I'll proceed with shutdown and volume detachment now | 15:58 |
fungi | sorry, caught up now, was focused on the openstack tc ptg sessions (still am but there was a short break) | 16:01 |
fungi | looks like the sjc3 mirror situation is already well in hand | 16:02 |
clarkb | dan_with: the server is in a SHUTOFF state and the volume is detached and available. I think you can proceed. You may want to double check those states apply to the instance and volume you want to modify | 16:03 |
dan_with | It looks like everything is clear. Can you re-attach the volume and let me look at the states? | 16:03 |
clarkb | dan_with: I can. Leave the instance shutoff for now right? | 16:04 |
dan_with | yes, correct. Leave shutoff for now | 16:04 |
clarkb | it is reattached now (in-use according to volume list) | 16:05 |
dan_with | hmmm. only one path. Can you detach it again please | 16:11 |
clarkb | yup one sec | 16:11 |
clarkb | done | 16:12 |
dan_with | okay try an attach again please | 16:15 |
clarkb | done | 16:16 |
dan_with | ok that's good. You can boot now. Thank you | 16:16 |
clarkb | it is booting now | 16:18 |
clarkb | I can ssh in and mount shows the lvm devices hosted on that volume as being mounted | 16:21 |
clarkb | dan_with: do you need to do more checks now that the service is up and using the volume or should we resume with normal operations at this point? | 16:21 |
dan_with | You can resume with normal operations at this point | 16:22 |
opendevreview | Merged opendev/zuul-providers master: Revert "Temporarily disable rax flex sjc3" https://review.opendev.org/c/opendev/zuul-providers/+/947018 | 16:22 |
opendevreview | Merged openstack/project-config master: Revert "Set rax flex sjc3 max-servers to 0 for mirror work" https://review.opendev.org/c/openstack/project-config/+/947016 | 16:26 |
dan_with | Thank you all | 16:27 |
clarkb | and thank you. This new cloud has been great even with the growing pains. And I think we're more than happy to be a guinea pig to shake things out | 16:28 |
fungi | thanks dan_with! | 16:28 |
noonedeadpunk | clarkb: ok, yes, thanks for the tip with IRC mode | 17:02 |
clarkb | noonedeadpunk: there is another thign to change one sec | 17:02 |
noonedeadpunk | I just also had to disable link previews, which was the actual issue | 17:03 |
clarkb | yes that was what I was going to look for | 17:04 |
clarkb | the two together make a big difference for my enjoyment of matrix as it becomes more dense | 17:04 |
noonedeadpunk | It;s in Settings -> Preferences -> Images, GIFs and videos | 17:05 |
noonedeadpunk | dunno why link previews in this section, but whatever :) | 17:05 |
noonedeadpunk | yes, indeed | 17:05 |
noonedeadpunk | it now looks really good and usable at least | 17:06 |
fungi | my main inconvenience with matrix at this point is the lack of good console-based client options. i may just need to start using https://matrix.org/ecosystem/clients/ement/ in emacs | 17:11 |
fungi | oh, actually there;s gomuks and matrix-commander i could try | 17:11 |
corvus | that brings a smile to my face | 17:12 |
clarkb | how to convert fungi to emacs: matrix. | 17:12 |
fungi | hah | 17:12 |
fungi | indeed | 17:12 |
corvus | best of all: no threads support :) | 17:12 |
fungi | i call that a feature | 17:12 |
corvus | me too | 17:12 |
clarkb | does anyone want ot weigh in on https://etherpad.opendev.org/p/O4aG1FCUb3o72NHRc0jQ before I send that announcement about the gerrit outage today? | 17:13 |
clarkb | I feel like I'm behind in prep but we've made consistent progress all week so I just need to stick to it | 17:13 |
corvus | lgtm; i'd omit the last pgraph | 17:15 |
fungi | agreed | 17:15 |
clarkb | cool I'll drop it | 17:15 |
fungi | the shorter the better, it doesn't add anything of value to the announcement itself | 17:16 |
clarkb | does that 1600 friday the 18th time work for anyone else? I'd much prefer to have at least one other person around | 17:16 |
clarkb | it is good friday | 17:16 |
clarkb | so I think it will be quiet but also people might not want to work that day | 17:17 |
fungi | oh, i was actually planning to be off (not because it's a holiday, but because it's my wedding anniversary) | 17:17 |
fungi | good reminder | 17:18 |
clarkb | fungi: do we want to do the 21st instead then? | 17:18 |
clarkb | I also expect monday after easter to be quiet | 17:18 |
fungi | i'm more able to help if it's on the 21st, but don't let me be the sole blocker if others want to do it on the 18th | 17:19 |
clarkb | I'm happy to do it the 21st too. I think that takes advantage of the holiday still | 17:25 |
clarkb | so do we want to upgrade etherpad now? | 18:10 |
clarkb | and I can remove the meetpad servers from the emergency file? | 18:10 |
clarkb | cardoe: also curious to know what browser you were using with meetpad. | 18:11 |
clarkb | I think we generally recommend chrom(e|ium) but people report firefox works well. Would be good to know if the audio drop out was on either of those or if we can keep recommending them | 18:11 |
clarkb | I'm removing meetpad02 and jvb02 from teh emergency file now. Will also remove the dfw3 mirror as it is still in there and doesn't need to be | 18:13 |
fungi | i was actually about to step out for a late lunch now that ptg is done, but am happy to help with etherpad double-checking when i get back | 18:18 |
fungi | up to you whether you want to upgrade it before then, but it seems unlikely to be a problem since we tested with a held node yesterday | 18:19 |
clarkb | ya I can approve it now | 18:19 |
fungi | i expect to be gone no more than an hour | 18:20 |
fungi | should be back at my keyboard by (likely wekk before) 19:30 utc | 18:20 |
fungi | s/wekk/well/ | 18:21 |
clarkb | I'm going to work on filling out the plan on https://etherpad.opendev.org/p/i_vt63v18c3RKX2VyCs3 for gerrit in the meantime | 18:21 |
clarkb | I think I decided we should do a gerrit init | 18:21 |
cardoe | clarkb: firefox on macos | 18:26 |
clarkb | cardoe: ack thanks. I wonder what was going on there. In the past similar issues have been related to brwoser permissions for audio and video but usually that affects you from the start not the middle | 18:27 |
cardoe | I'm on 137.0 I know I need to restart it | 18:27 |
clarkb | firefox did at one time automute things which we worked around by having that landing page before it starts to let audio through. Apparently that is enough for firefox to notice that you're opting into the media | 18:27 |
cardoe | It's just certain people I couldn't hear. | 18:27 |
cardoe | And JayF is always quiet. | 18:28 |
clarkb | yes JayF should increase mic volume :) its easier for us to decrease it in meetpad than increase it | 18:28 |
JayF | if you ever find me to be quiet please say so to me | 18:28 |
clarkb | JayF: you're always quiet | 18:28 |
JayF | hm | 18:29 |
JayF | I'll get my podcast producer to check oout the setup with me | 18:31 |
clarkb | I have a nice volume dial on my desk that I makes it easy to adjust when people are quiet so it isn't a big deal for me | 18:32 |
clarkb | side note: its sad we've moved away from so many purpose built tactile interfaces. They are nice | 18:32 |
clarkb | infra-root https://etherpad.opendev.org/p/i_vt63v18c3RKX2VyCs3 has a lot more detail in it now about the next steps I want to do today (starting mariadb and running gerrit init at least) and then followup steps. I'll get to actually doing some of that after etherpad is upgraded and lunch | 18:36 |
mordred | <clarkb> "side note: its sad we've moved..." <- we just got a new car, and it has a dedicated physical volume knob that is easily reachable while driving without looking (not up on the dash, down on the center console near the arm rest) Ton of other dedicated physical buttons too ... makes _all_ the difference compared to the everything-is-a-touchscreen world | 18:38 |
clarkb | ya my car is old and not new enoughfor all that new touchscreen stuff. I prefer it | 18:39 |
corvus | i have ordered a new corded headset (with a built-in volume control in the cable) | 18:44 |
* corvus beep beep beep | 18:44 | |
fungi | speaking of cars, i'll be afk a bit longer than planned. we're witnesses to an accident that occurred in the intersection front of us while we were waiting for the light to change, so busy giving statements now | 18:45 |
corvus | hope everyone's okay! thanks for doing your civic duty | 18:46 |
clarkb | no rush on my end. I'm just ticking things off the todo list | 18:46 |
clarkb | I did update the email to say april 21 instead of april 18 | 18:47 |
clarkb | I think that is likely to work better for having people around. Its monday which is annoying but the day after easter so also likely still quiet | 18:47 |
opendevreview | Merged opendev/system-config master: Update Etherpad to 2.3.0 https://review.opendev.org/c/opendev/system-config/+/946842 | 19:06 |
clarkb | etherpad is deploying now | 19:11 |
clarkb | it says it is up and healthy now | 19:13 |
clarkb | https://etherpad.opendev.org/p/i_vt63v18c3RKX2VyCs3 is stillreachable for me so I think it is generally happy | 19:13 |
clarkb | other etherpads I have open refresh and into what appears to be states consistent with the pre upgrade state. let me try in an incognito browser just ot make suer that caches aren't help me | 19:17 |
clarkb | still seems fine from there as well | 19:17 |
clarkb | fungi: I too am going to pause for lunch. When you get back if you can weigh in on the announcement with the 21st being the date that would be great then maybe also check the etherpad for the mariadb and gerrit init steps and let me know if those make sense to you. I'm going to do those next after lunch | 19:25 |
clarkb | and etherpad looks good to me. Any additional testing you want to do with etherpad would be great | 19:25 |
clarkb | I made some additional small edits to the gerrit outage announcement draft too | 19:29 |
clarkb | ok really pausing now back in a bit | 19:30 |
fungi | okay, back now, that was way longer than i expected, sorry | 19:56 |
fungi | corvus: yeah, we had a somewhat obstructed view because we were second in line for the light, but even though there was a line of cars in every direction who saw it happen, we were the only witnesses who stuck around to wait for first responders | 19:57 |
fungi | at least we weren't the only ones to call emergency services when it happened | 19:58 |
fungi | i too hope nobody was seriously hurt, it was a full-speed collision on a 50mph highway, vehicles spun all the way around from the impact | 19:58 |
opendevreview | Aurelio Jargas proposed zuul/zuul-jobs master: Remove Artifactory cleanup playbook https://review.opendev.org/c/zuul/zuul-jobs/+/947041 | 19:59 |
clarkb | I'm back now too. I'll hold off a few more minuets on the next gerrit steps to give you a chance to commetn on them but they should be all fine. None of them start the gerrit server | 20:03 |
fungi | clarkb: updated gerrit upgrade announcement lgtm, thanks! | 20:07 |
clarkb | fungi: cool and any concerns with starting mariadb and running gerrit init on the new review03 server? | 20:08 |
clarkb | mariadb should make backups happier and gerrit init should reduce the amount of stuff we need to copy from review02 | 20:08 |
fungi | nope, rechecking that etherpad was also partly a test of the new etherpad server | 20:08 |
clarkb | cool I'll work on all three things now then | 20:08 |
fungi | everything seems to be working as expected so far | 20:08 |
clarkb | starting with the stuff on review03 because if there are problems I want to know before I sned the announcement :) | 20:09 |
fungi | the final draft of pep 770 has been accepted for storing sbom metadata in *.dist-info/sboms | 20:14 |
clarkb | ok that went mostly well. gerrit init did not write out the plugins like I expected it to (I guess that happens when we start gerrit for real) and it generated new ssh keys for ecdsa and ed25519. I think we want to get ecdsa and ed25519 keys into config management so that seems like a next step | 20:15 |
clarkb | the state thinsg are in now is that mariadb is running but no other container is | 20:15 |
clarkb | and I need to figure out ssh keys | 20:15 |
fungi | yeah, obviously the private key material should go in our private hostvars, but overall i agree | 20:16 |
clarkb | yup | 20:16 |
clarkb | none of this seems like a problem preventing me from sending the announcement so I will do that then look at ssh keys | 20:16 |
clarkb | its interesting that ssh thinks it needs 3 different ecdsa keys to identify a host | 20:19 |
clarkb | I guess the idea is maximum client compatibility | 20:20 |
clarkb | announcement sent | 20:21 |
fungi | thanks!!! | 20:22 |
fungi | i've added it to my reminders too so i don't forget | 20:22 |
fungi | well, so i'm slightly less likely to forget anyway | 20:23 |
opendevreview | Clark Boylan proposed opendev/system-config master: Manage gerrit's ecdsa and ed25519 hostkeys https://review.opendev.org/c/opendev/system-config/+/947044 | 20:44 |
clarkb | I have not updated secrets yet. I kinda feel like deploying ^ is not something Iw ant to do on a Friday afternoon anyway | 20:44 |
clarkb | but maybe review that today and see what CI says then first thing monday we can update private vars and land that then work on synching the actual data to review03 | 20:46 |
fungi | i'm with you on that, even with not being the busiest ptg of all time i'm still feeling surprisingly drained | 20:46 |
clarkb | I'll WIP it now with a note that dealing with the private data has not bee ndone yet | 20:48 |
fungi | wfm, reviewing it now | 20:50 |
fungi | yeah, i think after we went to the effort of managing the rsa files, gerrit started spontaneously generating ecdsa files which weren't under configuration management | 20:54 |
clarkb | per the etherpad the upcoming prep steps are basically get ssh keys sorted on monday then copy real data for the database, git repos, and indexes. This will prime the synchronization so we don't have to do as much work later and it will allow us to test taht gerrit comes up and is functional with that syncronization which we will repeat on the 21st | 20:54 |
clarkb | fungi: ya | 20:54 |
clarkb | I made notes on copying data. We could also sync caches and logs if we want but I think leaving old caches behind is a good idea given our existing problems with them ( you will have to log back in though) and I feel like copying logs is a bit of a half lie we should avoid | 20:55 |
clarkb | we can refer to the old server to see old logs | 20:55 |
fungi | it also has dsa keys we aren't managing, but openssh 10 has removed support for them so i wouldn't bother | 20:56 |
clarkb | fungi: yup review03 does not have dsa keys. I think current gerrit ignores that file | 20:56 |
clarkb | its just still there from the before times and this upgrade will leave it behind | 20:56 |
fungi | seems likely cruft, yes | 20:57 |
fungi | it looks like the private key file format has support for `Comment: ...` header lines after the `-----BEGIN OPENSSH PRIVATE KEY-----` leader | 20:59 |
clarkb | TIL | 21:00 |
fungi | ssh-keygen -c -C "my new comment" | 21:00 |
fungi | or just pass -C at initial generation | 21:00 |
clarkb | and that different than the normal foo@host comment? | 21:01 |
clarkb | because that one gets encoded into the key itself in the private key. It is visible in the pubkey | 21:01 |
fungi | this is for private keys | 21:01 |
clarkb | right. The private key also has the foo@host encoded in it but not human readable iirc | 21:01 |
clarkb | (I ran into that when I put my keys in keepassxc because it would read the comment out of the encoded content and I had to reencode thinsg with better comments now that keepassxc made that info more valuable | 21:02 |
clarkb | something to experiement with in the future should I need to run them again | 21:02 |
clarkb | s/run them again/generate new keys/ | 21:03 |
clarkb | also I double checked and mariadb not running was the source of backup failures. This means the next round of backups should be happier as mariadb is running | 21:05 |
fungi | yeah, the ssh-keygen manpage suggests that the comment is initialized to user@host but can be changed using -c | 21:08 |
clarkb | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ee0/openstack/ee09f7271fb042b98e72850eb7154bcd/bridge99.opendev.org/ara-report/results/390.html this doesn't show gerrit init writing any keys so I think this is working | 21:12 |
fungi | so apparently the plaintext comment headers are a classic pem feature, not a new-style private key feature. the comment field in new-style openssh private keys is serialized and not obvious when looking at the raw file content | 21:13 |
fungi | however it's possible that plaintext comment lines outside the begin/end markers are simply ignored? | 21:14 |
clarkb | did we hear what caused cinder to stop using meetpad? | 21:28 |
JayF | the comment that they put in the feedback pad said they couldn't figure out how to do recording (and will learn before next ptg, implied) | 21:35 |
JayF | ln 13 https://etherpad.opendev.org/p/apr2025_ptg_feedback | 21:35 |
clarkb | thanks | 21:38 |
opendevreview | Clark Boylan proposed opendev/system-config master: Notify meetpad users when someone is recording https://review.opendev.org/c/opendev/system-config/+/947046 | 21:49 |
clarkb | so I don't think ^ was an option the last time I looked but gouthamr's mention of manually notifying peopel got me to check again and it seems like we can automate this now | 21:50 |
clarkb | probably worth testing to make sure it does it in a reasonable manner and rollback if not | 21:50 |
fungi | yeah, i approved the addition but we ought to be able to test at our leisure, e.g. next week sometimwe | 22:24 |
fungi | as for additional recording options, i think debian has their jitsi-meet set up with a plugin that streams server-side recording to peertube | 22:25 |
fungi | i'm not sure what the storage expectations for such a thing would be on the backend | 22:25 |
fungi | hopefully not much since the idea is to simulcast and record it into the streaming platform all in one go | 22:26 |
fungi | of course if you're also running a peertube node then that's going to have (fairly large) storage requirements of its own | 22:27 |
opendevreview | Merged opendev/system-config master: Notify meetpad users when someone is recording https://review.opendev.org/c/opendev/system-config/+/947046 | 22:37 |
fungi | deploy succeeded | 22:43 |
gouthamr | \o super nice | 23:14 |
Clark[m] | fungi: that requires running a jibri process per recording session. This is why I have never bothered as it takes our simple deployment and turns it into not simple at all | 23:58 |
Clark[m] | And basically jibri live streams to a sink like YouTube or peertube | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!