Rails: Do not generate ResourceQuota when using a shared namespace

MR:

Description

In Set default and maximum memory and CPU for work... (&11625 - closed) we introduced a new field in the agent config - max_resources_per_workspace. We implemented this by generating a Kubernetes Resource Quota. Kubernetes Resource Quotas are applicable at a Kubernetes Namespace level. This worked out well until now because each new workspace created a new namespace.

With this parent epic, we plan to introduce config to allow users to create all workspaces in a shared namespace. Thus, we should not generate this Resource Quota when this config option of shared_namespace is set to a non-empty value because there are no way in Kubernetes to apply a Resource Quota to specific pods in a namespace and neither are there such alternatives resources in Kubernetes.

In a followup, I'd like to revisit the discussion if we want to continue using native Kubernetes abstractions or just introduce this logic in Rails based on the logic described in https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resource-sharing-within-containers . The reason for not doing it in this issue is because it would require some more investigation which I'd like to pull out as a followup.

Impact assessment

When shared_namespace field is set to a non-empty string, users cannot set max_resources_per_workspace because we implement this as a Resource Quota which is only applicable in a namespace. In this case, all the workspaces share a namespace.

What users can do instead is create the ResourceQutoa with the required value themselves in the shared namespace.

Acceptance criteria

  • Model validations are added that enforce max_resources_per_workspace must be an empty hash if shared_namespace is set to a non-empty string.
  • When reconciliation occurs for a workspace, the resource quota is not generated if associated agent's configuration has shared_namespace set to a non-empty string.

Implementation plan

TODO: Fill out or delete (optional)
[Provide a high-level plan for implementation of this issue, including relevant technical and/or design details.]

Edited by Vishal Tak