The description given for option 1 is full of biasing statements without evidence. Many of them sound objectively incorrect to me, but I know I have bias in the opposite direction as the person who designed, implemented, and maintained Striker from 2016-2023.

Notes from previous discussion: The current implementation would present many blockers and require a lot of re-architecting to allow the development of planned features (see Requirements document). Extending Striker would also involve dealing with a production environment, and facing testing and permissions limitations. It would also prevent us from easily following the new Wikimedia front end standards (i.e., building with Vue.js)

Which discussion? Why is the referenced document private?

Also +1 to what Bryan said. I believe my work on T380114: Striker should use Codex (some of which is already live on https://toolsadmin-toolsbeta.wikimedia.org/) demonstrates that modern front-end tooling can be used with the current Striker codebase just fine.

Hey @bd808 and @taavi. Thank you both for sharing valuable information and resources regarding Striker's modernization. I'll make sure to reflect your comments in the description and remove the clear negative bias!

Please keep in mind that 1. this is an investigation task set up to gather evidence: all that's included in the description are (or should be) assumptions – I'll clarify that. 2. the task was created by a designer that doesn't have a specialized technical background and knowledge of the Striker codebase. I was just paraphrasing what was heard during a discussion, but I see how biasing and negative the statement for option 1 definitely is. 3. The task is WIP and pending to be reviewed by actual Toolforge engineers.

Thanks again!

Reworded the choices to reflect that's two things being decided at most, not one.

Are the various "running in k8s" statements in the task description specifically about deployment to the Kubernetes cluster within Toolforge itself, or something else?

In T383146#10442764, @bd808 wrote:

Are the various "running in k8s" statements in the task description specifically about deployment to the Kubernetes cluster within Toolforge itself, or something else?

Yep, within toolforge itself

Striker lives in the production realm today because it handles Developer account passwords and has write access to the LDAP directory and Keystone. Historically we have seen these credentials as too sensitive to allow within the Cloud VPS environment. The password auth system could be replaced with OIDC/SAML/whatever authentication from idp.wikimedia.org. The write access to LDAP is a pretty core need as Toolforge's authentication and authorization are LDAP based. It should be reasonably possible to split things into a client/server model that would put LDAP writes in a process that is deployed separately from user facing UI if there are compelling reasons to place the UI within the less-trusted Toolforge Kubernetes realm.