RFE: Kustomize plugin for ACM cluster provisioning spec

[tumido]

Consolidating open-infrastructure-labs/ops-issues#38 into a RFE here

Not entirely sure if I understand what's going on here -- but could writing a simple exec plugin for kustomize help with this? one that maybe we could share with others who want to do the same thing?

Originally posted by @HumairAK in open-infrastructure-labs/ops-issues#38 (comment)

That's a neat idea! Like ACM generator plugin.. that would work nicely. @HumairAK do you know if it's possible to compose kustomize plugins - like to use ksops generator first and then some other plugin on the same resource? Because we probably want the resource to be encrypted in git and then decrypt and generate configs from it...

Originally posted by @tumido in open-infrastructure-labs/ops-issues#38 (comment)

Ideally I would like to see this fixed in ACM itself :).

I think we could work around this with an exec plugin: we would probably need something that takes a single input document and uses it to generate both the ClusterDeployment resource and the install-config.yaml secret. If there's no "official" support for composing plugins, we can just call the ksops exec plugin ourselves, right? Or just sops -d, I guess.

Originally posted by @larsks in open-infrastructure-labs/ops-issues#38 (comment)

So, just thinking about this, if we want to DRY everything out, we'll need to read as input and emit in the appropriate places...

• The pull secret (which is used both in the provider connection and in install-config.yaml)
• The baremetal host information (which is used in the ClusterDeployment resource and in install-config.yaml)
• The ssh private key (used in the provider connection and in a secret referenced by the ClusterDeployment...twice)
• The ssh public key (used in the provider connection)
• The host key for the provisioner (used in the ClusterDeployment and in the provider connection

I think our deployment would end up looking like:

• a kustomization.yaml file with maybe (a) a namespace resource and (b) a generator
• a generator configuration that contains all the necessary input data

And that's it. And the entire configuration would then be generated by the kustomize plugin.

Originally posted by @larsks in open-infrastructure-labs/ops-issues#38 (comment)

[larsks]

https://github.com/operate-first/example-acm-install is an example of the configuration inputs necessary to drive a bare metal install using ACM.

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[sesheta]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

[sesheta]

@sesheta: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.