operate-first / blueprint

This is the blueprint for the Operate First Initiative
GNU General Public License v3.0
16 stars 16 forks source link

Add adr 0015 an amendment for cluster resource organization. #86

Closed HumairAK closed 3 years ago

HumairAK commented 3 years ago

Resolve: https://github.com/operate-first/apps/issues/610

larsks commented 3 years ago

With this ADR, and assuming we adopt my suggestion for core resources, we end up with something like:

.
├── apiextensions.k8s.io
│   └── customresourcedefinitions
│       ├── applications.argoproj.io.yaml
│       ├── appprojects.argoproj.io.yaml
│       ├── kfdefs.kfdef.apps.kubeflow.org.yaml
│       ├── observatoria.core.observatorium.io.yaml
│       ├── prowjobs.prow.k8s.io.yaml
│       └── rayclusters.cluster.ray.io.yaml
├── config.openshift.io
│   ├── oauths
│   │   └── cluster.yaml
│   └── projects
│       └── cluster.yaml
├── core
│   ├── namespaces
│   │   ├── apicurio-apicurio-registry.yaml
│   │   ├── argocd.yaml
│   │   ├── as-pushgateway.yaml
│   │   ├── b4mad-minecraft.yaml
│   │   ├── cnv-testing.yaml
│   │   ├── codait-advo.yaml
│   │   ├── democratic-csi.yaml
│   │   ├── ds-black-flake.yaml
│   │   ├── ds-example-project.yaml
│   │   ├── ds-ml-workflows-ws.yaml
│   │   ├── fde-audio-decoder-demo.yaml
│   │   ├── hostpath-provisioner.yaml
│   │   ├── kubeflow.yaml
[...]
larsks commented 3 years ago

Some random thoughts on this topic from over the weekend; writing them here so as not to forget:

kustomization.yaml

resource quotas

Some Namespaces include custom resource quotas (e.g., base/opf-datacatalog/resourcequota.yaml). Currently, these are all named "custom". If we reorganize everything in base/ by <apiversion>/<kind>/<name>, all these resource quotas end up in the same place. With this adr, should we:

image registry

Should we treat the image registry as a top-level application? Currently, we have a PersistentVolumeClaim in base/imageregistryconfigs/cluster, but this seems out of place (it's really not a cluster-wide resource).

HumairAK commented 3 years ago

Give the resource quotas unique names and put them in base/core/resourcequotas/? I submitted a pr to update the names in operate-first/apps#621

I think I like this option over the others

Should we treat the image registry as a top-level application?....(it's really not a cluster-wide resource).

Well..neither are operator-groups, I think cluster-scope app is not just cluster-resources but more like privileged resources, and resources in privileged locations, I personally don't mind having PersistentVolumeClaim in cluster-scope for niche cases such as this. An app for 2 files seems overkill imo.

tumido commented 3 years ago

I agree with @HumairAK. The cluster-scope or cluster-resources is maybe named wrong - the purpose for it is to host all resources which are not allowed to be touched by regular project admins. OperatorGroups, Subscriptions, ResourceQuotas are all namespaced resources we define here and it's because we don't want users to control those...

The Image registry is a specific case - the Config resource is a cluster-scoped resource that is deployed on the cluster from the start and we're just patching few properties of it - some other spec properties are even managed by the cluster itself. It's a singleton in the whole cluster. And it in our case, it requires a PVC.

If you want the Image Registry as a separate app, you would still need to split those 2 resources up and let the Config live in the cluster-scope and the PVC in a separate application with a single resource only. That seems wrong to me. Hence I chose to include PVC together with it in the cluster-scope.

tumido commented 3 years ago

Give the resource quotas unique names and put them in base/core/resourcequotas/? I submitted a pr to update the names in operate-first/apps#621

:+1: on the resource quotas. I think that's the best option we have.

sesheta commented 3 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: larsks, tumido

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/operate-first/blueprint/blob/main/OWNERS)~~ [tumido] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment