search

linki / cloudformation-operator

A Kubernetes operator for managing CloudFormation stacks via a CustomResource
MIT License
102 stars 26 forks source link

allow duplicate stack names across Kubernetes namespaces #5

Open linki opened 6 years ago

spa-87 commented 5 years ago

Personally I would prefer to avoid this kind of feature. CloudFormation doesn't allow to have stacks with the same names in the scope of one region/account. Moreover, I would prefer to make CRD scope to Cluster by default in order to avoid confusion (it isn't critical though, it's a matter of the individual configuration and doesn't require changes at the operator code). Currently matching is pretty obvious k8s stack == CFN stack. If we decide to implement the current feature, a single option is adding prefix/suffix by a namespace to a stack name. It will lead to backward-incompatible changes at stack names and problems with migration to the new version. Thus if this feature is implemented once, it should be optional and disabled by default, IMHO.

linki commented 5 years ago

@spa-87 Thanks for sharing your opinion.

mukaibot commented 5 years ago

My organisation is currently considering using Kubernetes Operators to manage Cloudformation stacks across a large number of accounts (well, ~150 accounts is a significant number where I am based).

I've just found your project @linki and I think this is awesome! Thank you so much for open sourcing this!

I think this feature would be required for us though, because for example we would want the same stack (probably with parameters) to be present in all our accounts, and from the description of this issue, the operator requires stack names to be unique. Would you consider a PR if we decide to use some of your code?

linki commented 5 years ago

Hi @mukaibot, thanks for your nice words. Please see my answer regarding the status of this project before starting to use it seriously: https://github.com/linki/cloudformation-operator/issues/20#issuecomment-453472383.

Also take a closer look at https://github.com/awslabs/aws-service-operator which takes a slightly different approach.

I would be happy to accept a PR implementing this but I would also consider @spa-87 concerns as well.

linki commented 5 years ago

One point in favour of a cluster-wide CRD and a 1:1 mapping from resource name to CF stack name is:

although how would outputs/refs work then, are they remapped somehow or just unsupported?

cuppett commented 3 years ago

Have added explicit .spec.stackName here:

https://github.com/cuppett/aws-cloudformation-controller/commit/b41031363ceb9adbf5ce4bbed35f97784962a775

When not specified it'll tack on a crc32 hash of the Kubernetes UID to disambiguate.

Both those mechanisms lets the object names be re-used across namespaces. For existing stacks, requires the newer merges and objects first (where .status.statusId is captured so they can be found).