We are declining this request because, under current policy, this use case does not qualify for a floating IP.

Trying with just the builds-api openapi.yaml and openapi-generator, it doesn't like .common section

In T366147#9842048, @dcaro wrote:

Nope, it's the path matching expression, now the paths start with /v1/tool/... not /v1/build/... to be fixed on https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-cli/-/merge_requests/71

Done, quota increased by 1TB.

Using floating ips for http/https endpoints and the use of vanity domains is currently a bit of a gray zone. We will discuss this request during our next WMCS team meeting (2024-05-30) and get back to you then.

Hmm, we might not be the best folks to decide which term is more descriptive/unambiguous because we're too deep in the soup. 🙈 Could we somehow run a quick poll?

Robot accounts still don't have update permissions on project quotas. After bringing it up in the CNCF harbor channel, one of the maintainers said that I could file an issue, which they would then turn into a proper feature proposal.

In T362075#9806795, @Raymond_Ndibe wrote:

I have a thing against reuse-from. It is not immediately clear what it means by just looking at it. depends-on is a more descriptive name if I understand the supposed meaning of reuse-from correctly. In contrast reuse-from sounds like we are somehow reusing the configuration of a particular component in another. Obviously this is not already set in stone but it's important to point it out

@Albertoleoncio I know you managed to get this working and wrote some docs about it, would you mind adding a link in this task?

Returning to the original intent of this task, there seem to only be two good alternatives, OpenAPI Generator and Swagger Codegen (links in task description). Of these, my recommendation would be OpenAPI Generator based on discussion in earlier comments.

I think this is solved by T362299: [api-gateway] Add a python server to serve consolidated openapi docs which was the implementation of this exploratory task. Feel free to reopen if you disagree.

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.