In T7230#143538, @RhinosF1 wrote:

In T7230#143535, @John wrote:

Load times for mw*, so this is MediaWiki infrastructure. Please tag tasks correctly on future.

It's as far as we know to now caused by gluster.

Load times for mw*, so this is MediaWiki infrastructure. Please tag tasks correctly on future.

https://github.com/miraheze/puppet/commit/8fdd5bd235142e5103bdeadef3d2e7b9ab62b489 ?

I have created an account on OpenCVE and populated it with products/services we are using. Password can be found on Private Git.

In T7214#143260, @Dmehus wrote:

In T7214#143215, @RhinosF1 wrote:

In T7214#143206, @Void wrote:

https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories ??

Our main focus is on the allowing others to view and managing private patches.

I could be wrong, but I think what @Void is suggesting with this comment is that the GitHub docs for creating security advisories in GitHub exist and are, presumably, fairly adequate, so there's not a real need to create our own tech docs?

In T7213#143182, @Void wrote:

It seems that the visibility check is awkwardly implemented if each interface that exposes a setting needs to independently check the visibility.

If this can’t be done as a single source of truth, my personal opinion would be to get rid of public/private settings until they can be done safely and securely.

In T7195#142780, @RhinosF1 wrote:

In T7195#142778, @John wrote:

@Paladox can you take a look just to see if it’s only an OOM and nothing more serious?

Why is this tagged with the mediawiki team. We have minimal control and zero knowledge of gluster.

@Paladox can you take a look just to see if it’s only an OOM and nothing more serious?

/usr/local/bin/logsalmsg test

@Reception123; can this be closed? Grafana shows this isn’t irregular and there’s a task already opened to increase capacity that is blocked in MWSRE.

@Southparkfan updates the above?

Grafana shows an increase in requests/s on both cp10 and cp11.

@Southparkfan See the above please

Rename worked when I did:

Ignore the above - problem was caused by aaawiki not have a cache file on test3.

Deployment of jobrunner on all servers has now happened. Per the above, this is blocked on MediaWiki (SRE) deciding when they wish to deploy an additional two servers.

Steps to enact the above would be:

@Paladox are you okay to have a look at this?

Added monitoring, removed production error as no stack trace/ID/link was provided for a production error

https://github.com/miraheze/jobrunner-service/compare/de7d72b68abc...7e6175d56b4e

It looks like a useful service, so we should definitely give it a try and see from a security perspective.

Changes never got deployed on the server, this has been fixed now.

T7107

Because of our monitoring, we’re doing fairly intensive Lua scripts on almost a 100k keys, this can take up to 2 seconds to run. We have set our connectTimeout in Redis has being 2s (https://github.com/miraheze/mw-config/blob/master/GlobalCache.php#L48).

Redis software not the jobqueue software as this is manually ran, not a job

https://grafana.miraheze.org/d/3L3WYylMz/mediawiki-job-queue?orgId=1

https://github.com/miraheze/puppet/blob/master/modules/prometheus/files/redis/jobQueueCollector.lua

Basic LUA script to handle this:

In T7073#140612, @Reception123 wrote:

Since there are more uses than MediaWiki, should this be tagged as MediaWiki (SRE) only?

Is there a use case for this that the ES data source wouldn’t fulfil? Is this the approach MediaWiki (SRE) wish to take? If so this would fall under the MW team to implement as part of their task as without a use case for Infra, what’s the point in implementing something unused?

Not blocked on external entity

In T7046#139478, @RhinosF1 wrote:

We still need something to test on though. I suggest we use test3 at first. We therefore just need to know which db to put the cached info on.

Sounds like there isn't a problem then?

Do we have an update on this? Also, who is taking responsibility for this?

Before I can review this, more information needs to be provided.

Approved, with spending authorisation by @Southparkfan

Approved for cloud4.

T4302 - if that task gets declined in the future then this task would need re-opening.

Get a list of all h-sha1ById, loop over them running a HLEN on the key will return how many unclaimed jobs there are by job type - add these up and then the data exists for both the whole jobqueue but also per job (and if you want to go further, each job type by each wiki)

Reviewing the stats already put up by @Paladox and looking into Dovecot's stats facility in more detail, I don't believe we would gain any new information from Dovecot stats as the Postfix ones already cover all bases of mail, including connections, logins and auth failures.