I have major concerns about indefinitely postponing the implementation of T325067: cloudcumin: decide sudoers rules for users without global root. This is effectively creating a split where non-staff, who've previously had roughly the equivalent access as staff do in almost the entire WMCS infrastructure, will now feel like second-class citizens compared to those who have access to the new and shiny hosts. I'm also worried that it'll introduce a bunch of subtle bugs in the differences between local and cloudcumin setups, for example with the various sudo hacks currently present in the repository.

Philosophical question: is Spicerack the right tool for all of these use cases? Could some CloudVPS tasks be performed with other tools, e.g. Terraform?

My feeling is that the current setup should focus on the needs of WMCS-maintained projects (Cloud VPS, Toolforge, etc.). Other WMF people who're used to Spicerack might also be interested in using some variation of the setup for their projects, but Terraform and similar projects is likely a better option to those not familiar with either of the options.

@taavi thanks for your comment. I think I can speak on behalf of the WMCS team if I say that we definitely do not want volunteers (and staff without global root) to feel like second-class citizens. I agree that T325067 is an important task and I created this parent task to provide more context and better define the use cases that make it important.

My feeling is that the current setup should focus on the needs of WMCS-maintained projects (Cloud VPS, Toolforge, etc.).

This feels like a good perimeter to me, and means that we could leave out of scope (at least initially) the last user group I defined in the task description ("WMCS users managing a CloudVPS project"), while keeping in scope the third group ("volunteers working on WMCS admin tasks").

I will discuss this with @Volans later this month (I'm on holiday next week), but in the meantime I think another thing that would be useful is to describe in the comments below specific scenarios, e.g. referencing specific tasks or activities where not having access to a shared cookbook host is a hindrance. If we spell out a few use cases, we will clarify the used needs, and we will strengthen the case for having a shared host that is accessible to non-staff/non-roots.

In T343330#9082805, @fnegri wrote:

I will discuss this with @Volans later this month (I'm on holiday next week), but in the meantime I think another thing that would be useful is to describe in the comments below specific scenarios, e.g. referencing specific tasks or activities where not having access to a shared cookbook host is a hindrance. If we spell out a few use cases, we will clarify the used needs, and we will strengthen the case for having a shared host that is accessible to non-staff/non-roots.

Thanks!

One current example is the Toolofrge Kubernetes upgrade process, which is fairly often something I do. T343869: Turn wmcs-k8s-node-upgrade.py into a set of cookbooks is turning a current script into proper cookbooks, and the full cluster upgrade takes a while so it'd be great if it could run in a tmux on a cloudcumin host so I didn't have to worry about my laptop suspending or losing network connectivity for a couple of hours.

Could some CloudVPS tasks be performed with other tools, e.g. Terraform?

On 2023-08-10 Hashicorp announced their intent to re-license Terraform and other products under the non-OSI approved Business Source License. I believe this change should cause a general re-evaluation of WMCS efforts to support or use their tool.

In T343330#9087171, @bd808 wrote:

Could some CloudVPS tasks be performed with other tools, e.g. Terraform?

On 2023-08-10 Hashicorp announced their intent to re-license Terraform and other products under the non-OSI approved Business Source License. I believe this change should cause a general re-evaluation of WMCS efforts to support or use their tool.

hot of the press but perhpas https://opentf.org/announcement