Document pkg to (re) implement common kustomize primitives about airshipctl

[teoyaomiqui]

I've started working on this.

[airshipbot]

New Related Change: https://review.opendev.org/710084
Authored By: Kostyantyn Kalynovskyi ([email protected])

[airshipbot]

New Related Change: https://review.opendev.org/709252
Authored By: Kostyantyn Kalynovskyi ([email protected])

[alanmeadows]

I'd also advocate that for instance, https://review.opendev.org/#/c/693238/21/pkg/cluster/initinfra/infra.go L84 another example that would benefit from centralization in the Bundle itself.

[teoyaomiqui]

Introduce heavier bundle filtering

https://review.opendev.org/#/c/709252/ this patch set introduces annotationselector and label selector objects, and not just strings. I would like to have small discussion about this. Document labeling appears to be more a little more complex than we expected.
Small labels like

airshipt.org/ephemral: "true"
airshipit.org/target: "true"
airshipit.org/deploy: "true"

doesn't seem to be sufficient

what i've run into, is for example, you have baremetalhost object for ephemeral host. Do we deploy it to ephemeral cluster? I think its better not, because there is no consumer for that document, we don't want metal.io to redeploy it, or do anything with it. Do we deploy it to Target cluster? I am sure, some of the environments, may not have a spare server, and should like ephemeral host to be redeployed as compute or control-plane node. This is the first example, we may hit much more in the future.

So in this example, we have a document, that belongs to ephemeral and target cluster at the same time, but it should not be passed to k8s cluster of ephemeral cluster. This kind of complexity, leads to multiplying labels:

target: true
deploy-ephemeral: true
deploy-target:false
...

many more to come (and to keep in mind, that label is a string, not a boolean, so we create filters based on strings, == "True" or =="true", which is not very good looking.

Maybe we should introduce an object, document-meta, which would be stored in document annotations hold information for this:

type DocumentMeta struct {
  cluster map[string]ClusterMeta
}
type ClusterMeta struct {
  DeployToK8s bool `json:"deploy"`
}

I am not sure about how this will work with kustomize annotation transformers though.

But because i see very much expansion and upcoming changes to how we label/annotate and filter documents, i thought it would be better to abstract from using strings and relay on standalone objects instead.