Consider using a different key than example.com/project

[etsauer]

No description provided.

[etsauer]

@jkupferer what do you think of using the label example.com/directory?

[jkupferer]

"Project" makes a lot of sense here if it were not for OpenShift already using the word for namespace
You said "component" was also not available because that means something else

I think what we want is something that conveys something like what is this part of, what declarative config "owns" this thing.

I don't think "directory" captures that idea.

When in doubt, I usually just go with a longer name: example.com/declarative-config?

[etsauer]

@jkupferer yeah, so "component" is currently being used to describe the level below "project", however that could also be debated.

So currently, it looks like this:

$ tree simple-bootstrap/
simple-bootstrap/ # example.com/project=simple-bootstrap
├── 0-namespaces # example.com/component=namespaces
│   ├── cluster-ops.yaml
│   ├── deleteable.yaml
│   └── namespace-config-operator.yaml
├── 1-operators # example.com/component=operators
│   └── namespace-config-operator.yaml
├── 2-rbac # example.com/component=rbac
│   └── cluster-admins-rolebinding.yaml
└── 3-operator-configs # example.com/component=operator-config
    ├── gitops-job.yaml
    └── sandbox-userconfig.yaml

I'm open to renaming both of those keys.

[jkupferer]

What about config.example.com/name for the top level which should reflect the name configuration repository? and config.example.com/component for the next level?

[etsauer]

Interesting... would you change the annotation prefixes to config.example.com as well or leave them as they are?

[jkupferer]

I would change those too. I believe it fits established pattern to use subdomains like this?

[etsauer]

ok, I'm cool with this. Will open a PR.