In T365146#9986170, @dancy wrote:

Regarding:

# dependencies share the same project
   project = deps[0].project

Gerrit doesn't enforce this. The same Change-Id can be used across projects.

I tried to interpret the criteria into some psuedo-code. I attempted to capture all the cases in the criteria and explain the scenarios. I'm wondering if for the boundary scenario, such as for an unlikely dependency trail like [0]Core->[1]config->[2]core->[3]core, should we just consider the selected depends-on's branch as the the target branch (ex. change 3 is relevant if targeting same branch as change 2) for consistency's sake? As you mentioned in another comment this scenario is unlikely and it's hard to interpret the actual intention.

At that point we don't know which of the wmf version branches are required to contain the commit in K.

Adding a persistent volume for /var/www/html/wikis will allow the wikis to persist on reboot. No other volume is needed.

D belongs to the MW configuration repo and K belongs to a MW code repo --> If K doesn't target master it will vote in favor if, and only if, it's been merged or passed as root change in the command line. If it targets master it will vote in favor if, and only if, it's been merged and its commit is in all deployable branches (as determined by the "change/_/in" endpoint from Gerrit)

Thanks @Ladsgroup. I've been monitoring since then and I think you are right.

I have rolled back the train because of a higher than normal DBQueryError rate. I've created a bug task with the top DB error from logstash and added it as unbreak now.

Some things that need to happen on the patchdemo side:
After pushing "create demo":

• Print logs for catalyst media wiki creation
• On completion, make sure open wiki button goes to the right place
• Fix “you can log in as…text” by either adding those to our mediawiki chart or removing the text

I'm wondering if we want to change the terminology of 'Production branch' to 'Active branch' to match the terminology that is all over scap (active wikiversions, etc.)?

In T364556#9783812, @Zabe wrote:

Dupe of T364538: Voting in U4C election is not possible anymore?

I rolled back to testwikis due to errors caused by T364428.

In T362987#9740026, @jnuche wrote:

I'm not clear on what the proposed code changes are. I think what is mentioned in the "relevant dependencies" and "backport vote" sections are already implemented in the code (or in the case of change_in, have a MR to do so), except for maybe reducing the number of confirmation prompts. Can you clarify which parts are missing or whether it is that you would like to change the structure of the dependency checking process?

As a first step I want to make sure that we all agree on terminology and a set of acceptance criteria (do all my points above look correct? did I miss something?)

Then we can look at the current state of the code (including the MR you mentioned) and discuss any required code changes. If we verify that we are already checking the agreed upon A/C (and only those A/C) then that aspect of the changes is complete and doesn't require extra work :)

The other piece of work regarding the code would be a refactor to make the code match the agreed upon terminology. Quite often when we talk about backport issues it's hard to tell what we are referring to and we have to start remembering how things work from scratch. I think that having a design document and a code that matches it would really help us in the future to have a reference and a starting point for discussions.

I'm not clear on what the proposed code changes are. I think what is mentioned in the "relevant dependencies" and "backport vote" sections are already implemented in the code (or in the case of change_in, have a MR to do so), except for maybe reducing the number of confirmation prompts. Can you clarify which parts are missing or whether it is that you would like to change the structure of the dependency checking process?

Mysql db is not in the patchdemo container so when running, a db connection is needed. Environment variables to be in the image are DB_HOST, DB_USER, DB_PASS, DB_DATABASE.

Sorry, false alarm! Looks okay now.

Is this related to the bug that was fixed earlier today?

I made some changes to the script to get it working on our vm and put them here: https://gitlab.wikimedia.org/repos/qte/catalyst/patchdemo/-/tree/catalyst?ref_type=heads

stack trace of timout errors

@matmarex seems like spam but quite a few of these are popping up since deploying T358112

In T358112#9563880, @hoo wrote:

I just found out that this happens only if the viewer has advanced permission to see hidden accounts. Will update the description.

Yes, I think that is the correct assessment (the revert to bare metal did not fix the error. But I'm also not sure what configuration changes were needed to make this change on the mediawiki side that needed a scap deploy), so we still need to figure out how to solve this issue.

isn't a deployment of changeprop in kubernetes needed here? I don't think scap does this.

I wanted to see this rogue button so I logged out but (un)fortunately it was in English for me

Looks like we've had an increase in errors since deploying the train today

https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/tree/extension-templates?ref_type=heads

I updated the spec based on details in the miro board. I made some assumptions about the schema that might need changing, as well as renamed 'service' to 'resource' since I thought it was a bit confusing to refer to things like extensions and skins as services. I also removed DELETE /environments since it wasn't on the miro board (added DELETE /environments/:id).

In T343967#9151215, @dancy wrote:

@jeena Ping to publish a new scap release.

I think this needs to be backported since the branch commit for wmf.25 already happened before merge

Hi @xSavitar, this feature exists already. I'll be adding an integration test for it soon.

We plan to make a new scap release and deploy the changes that address this on June 15