Page MenuHomeMiraheze

New Resource Request for MediaWiki-Extension-Updates
Closed, DeclinedPublic

Description

Number of servers requested: not sure where best to put, new VM not necessarily needed
Service: MediaWiki Updates (requires Flask, Apache/Nginx, Git)
Processor: enough for git + flask
Memory: ?
Disk: MediaWiki is 5.6GB and we need a numerous branches so enough for that.
Network: external IP for access to GitHub

This will also need access to a database to cache data.

Justification for request: Dependabot causes nearly as much spam as use, MW Engineering are exploring ways we can track the status of extensions, view changes and automate only needed pull requests.

Endorsement by Engineering Manager (MediaWiki) or Site Reliability Engineer: @Reception123, as discussed with you, can you review?

Event Timeline

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

  1. Accurate resource requirements need to be provided, the current ones are unclear.
  2. If this serves a single web service which would be a ‘monitoring’ service, is there any reason why either mon2 couldn’t be used, or it could even be distributed among the mw* cluster?
  3. If a new VM is created, what would its dedicated purpose be and what would its naming scheme be?

My advice would be to work on test3 until information is clear and the suggestion is stable with a clear understanding of what is being requested and why - as currently I don’t see a need for dedicated VM resources to be allocated. I’ll discuss this with @Reception123 before making a decision for now.

I think before we consider doing this, we also need to have a feasible implementation plan for a system. (Meaning that we don't do it and it ends up not being feasable with our resources)

I suggest we start on test3.

I guess the next question is which db to put the cache on for the commit info.

John added a subscriber: John.

I think before we consider doing this, we also need to have a feasible implementation plan for a system. (Meaning that we don't do it and it ends up not being feasable with our resources)

I agree that before actual approval we need a more detailed plan

The plan for me is that we will have a web based interface that will list every extension/skin, it's latest commit, the commit we have deployed, whether it's i18n only and a link to the diff.

I shared some links yesterday with how we can get the info.

The plan for me is that we will have a web based interface that will list every extension/skin, it's latest commit, the commit we have deployed, whether it's i18n only and a link to the diff.

I shared some links yesterday with how we can get the info.

I know the plan to do with this, what I'm saying is we need a plan to implement it. I mean that we need to be sure we can actually implement that before we consider this.

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.

John claimed this task.

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.

db12 or db13.