05:09 <wb9688> Lyude: Ah, OK, no problem

05:21 <bentiss> emersion: thanks! and I am surprised you had to bump redis, but I guess this is due to the heavy load on gitlab

05:22 <bentiss> emersion: and yes, we do have monitoring for the cluster. There are 3 things you can use: influxdb dashboard for metrics, loki for general logging and elasticsearch for nginx debugging

05:23 <bentiss> but currently elasticserach is down, because it was using too much disk, and I haven't re-enabled it

05:33 <daniels> emersion: yeah, it sounds like the old FS (just for cache) isn’t happy, but luckily it’s throwaway. thanks for fixing!

08:54 <pq> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/96 "Allow contributions from GitLab private e-mail" - would anyone want to comment on that?

09:08 <__tim> I think it's important to have functional e-mail addresses for contributors, but I realise it's a weak argument since people change jobs/e-mails etc all the time anyway and it's hard to police too (and if someone made up a fake one that would be difficult to spot as well, same for a fake name). Doesn't mean that it's not desirable imho

09:09 <__tim> but if someone cares about their privacy you would expect they'd have some throwaway e-mail address for the purpose anyway?

09:10 <mceier> it might be also about getting spam

09:10 <pq> I meant, comment in the issue, not here. :-)

09:11 <pq> fd.o has CoC, so if there can be a wider agreement about this topic, that would be awesome

09:13 <__tim> I suspect we're more likely to agree on a standardised fdo coding style ;)

09:17 <mceier> for me more important is a link to issue/rationale of given commit than a mail address or name of the author ;)

09:47 <pq> only for projects that have adopted DCO, naturally

09:47 <pq> I have no idea who to even ask what would be sensible.

09:49 <pq> and if I say you cannot contribute without a valid looking email address, is that discrimination? which falls under the CoC I believe

09:49 <emersion> why would it be discrimination?

09:50 <pq> why would it not be?

09:50 <pq> I've no idea

09:50 <emersion> requirements to get a GitLab account are pretty high anyways: valid email address, google captcha, javascript

09:51 <pq> that's a different email address, one that gitlab will not expose if you so want, right?

09:52 <emersion> asking for a GitLab handle to contribute is discriminatory in the first place, by that definition

09:53 <pq> I suppose it is

09:54 <emersion> fwiw, i agree that the GitLab email address should be okay

09:54 <pq> I'm clearly totally clueless about what's reasonable here.

10:05 <wb9688> pq: Yeah, you can choose to not expose it, which I did

10:20 <wb9688> pq: And yes, creating a GitLab account requires an e-mail address that needs to be verified by clicking a link in your e-mail

12:31 <jenatali> Looks like gitlab might be down again

12:33 <mupuf> yep :s

12:38 <mupuf> bentiss, daniels, emersion: ^

12:38 <jenatali> emersion bentiss daniels ^^

12:49 <emersion> 1:M 29 Jun 2022 12:48:30.567 # Short write while writing to the AOF file: (nwritten=97, expected=613)

12:51 <daniels> sigh @ redis

12:51 <emersion> not sure why it's filling up

12:51 <emersion> and i can't even edit gitlab-prod-redis-master-0 again

12:51 <emersion> error: the server doesn't have a resource type "gitlab-prod-redis-master-0"

12:55 <daniels> I'm trying to see if I can make it just not persist its cache in the first place

12:55 <daniels> since, well, it's a cache

12:58 <daniels> emersion: fwiw if this works (just have to manually resync helm-gitlab-omnibus with the recent changes since I can't pull the repo ...) then we won't have to worry about the PVC ever

13:15 <ofourdan> hey, I am getting a 502 "GitLab is taking too much time to respond" error when trying to access https://gitlab.freedesktop.org/ - Is that a known current issue?

13:18 <pq> yes

13:18 <ofourdan> alright :)

13:21 <daniels> and it's back, hopefully for good

13:22 <ofourdan> thanks!

13:22 <pq> Thank you! \o/

13:22 <daniels> np :)

18:02 <jenatali> > botocore.exceptions.EndpointConnectionError: Could not connect to the endpoint URL: "https://minio-packet.freedesktop.org/"

18:03 <anholt_> same

18:03 <anholt_> happened in the last 10 min I'd say

18:04 <anholt_> ping bentiss, emersion_, daniels

18:04 <daniels> hmm, yeah /dev/md127 1.3T 1.2T 67G 95% /var/lib/rancher

18:05 <daniels> 545GB of artifacts, 609GB of mesa-lava; I think the latter should probably expire sooner

18:07 <anholt_> what are we at currently for mesa-lava artifacts expiry?

18:10 <daniels> I'll tell you in a sec

18:24 <daniels> it's back

18:24 <daniels> so yeah, I remember now that there's no automatic deletion, because we don't know how long we'll need the rootfs for

18:26 <daniels> and at the time we sort of said 'errr, I guess we should figure out some kind of policy which expires out files which aren't in mesa/ and were created $weeks ago, but let's cross that bridge when we come to it'

18:39 <daniels> ok, filed an internal ticket so we can stop relying on minio-packet to bounce things through, and itmt we've got enough space that we've got a year to solve it

18:39 <daniels> it's less a bridge than lashing a raft together, but it'll do