Here, we are only talking about allowing tools to set up and use s3-style buckets, correct? Is there any intersection/dependency between this use case and enabling ceph-backed PVCs in toolforge k8s, e.g. the toolforge k8s nodes being able to access and authenticate with the ceph cluster?

Option 2 seems to me like the obviously good choice :)

In T363544#9772459, @LucasWerkmeister wrote:

CC @Slst2020 who just ran toolforge envvars list in T362062: [Session] Toolforge & Cloud VPS demos (the only variable that was truncated at 50 characters was the Django secret key) – she said she’s gonna change the credentials afterwards, but IMHO it would’ve been better if the command hadn’t shown them to the whole room in the first place :)

Just acknowledging that I've seen this discussion, but that I don't know enough about this topic to have a preference.

Option 1 for an MVP, then iterate on it as needed.

https://kubernetes.io/docs/concepts/services-networking/network-policies/#targeting-multiple-namespaces-by-label

In this scenario, your Egress NetworkPolicy targets more than one namespace using their label names. For this to work, you need to label the target namespaces. For example:

kubectl label namespace frontend namespace=frontend
kubectl label namespace backend namespace=backend

Add the labels under namespaceSelector in your NetworkPolicy document. For example:

+1

In T362299#9705965, @dcaro wrote:

For the deployment we can reuse the same that's there already and add two containers

Indeed, this seems to have been an issue only in (my particular setup of) lima-kilo. Sorry for the confusion! Non-admin permissions are not broken in Harbor 2.10. Closing this as invalid and moving on. I've tested maintain-harbor in production (!) and nothing breaks.

In T361804#9691960, @dcaro wrote:

I do think that it's good to keep the page somewhat updated, so if you are creating a new repo or similar you have a reference to look up for (as it is, I would probably re-invent whatever checks I used in some other random repo instead).

I don't see that we have to be explicit in the wiki page about what we currently do, other than recommending "follow the conventions in whatever repository you are contributing to", "dare propose changes as you see fit", and if you start a new repository "use common sense and consult with whomever else will be the main contributors".

In T361804#9691856, @dcaro wrote:

I think there might be something not clear in the options xd

Anything with 'B' in front is non-prescriptive (A -> prescriptive, B -> non-prescriptive), the number is just the checks to do (if paired with A then in a prescriptive manner, if paired with B in a non-prescriptive one).

Can you elaborate on why you see B1 as the only one non-prescriptive? (so I can modify the wording/etc.)

I want option 1 because it's the only one that is not prescriptive. To me it's a coincidence that option 5 aligns with what I think would happen by going with B1. That said, if the majority vote is B5, I'm fine with that.

My preference would be to continue with what I perceive is the status quo, which I would describe as something like this:

Upon further investigation, this seems to have been an artifact of my lima-kilo harbor instance, where I had a few test projects that weren't created/admin'd by maintain-harbor. I will do a bit more testing, but hopefully this turns out to be a non-issue.

In T361007#9688376, @CodeReviewBot wrote:

sstefanova opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/merge_requests/83

dev: add AGPL-3.0-only license

To clarify, do we want AGPL-3.0-only or AGPL-3.0-or-later?

To do this right, we need to add a license notice to every file in the repo in addition to a COPYING file. Is that correct?

In T360509#9645133, @dcaro wrote:

Note also that maintain-harbor already manages the policies for all the other projects in harbor.

Using the new Build Service is now the recommended method for deploying Django applications on Toolforge. I think a better idea would be to:

The current error message probably comes from the envvars API that envvars-cli talks to. The repo is here: https://gitlab.wikimedia.org/repos/cloud/toolforge/envvars-api

Do we want to expose the /healthz and /metrics endpoints in the unified spec?