allow duplicate stack names across Kubernetes namespaces

[linki]

No description provided.

[spa-87]

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]

@spa-87 Thanks for sharing your opinion.

[mukaibot]

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]

Hi @mukaibot, thanks for your nice words. Please see my answer regarding the status of this project before starting to use it seriously: #20 (comment).

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]

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]

Have added explicit .spec.stackName here:

cuppett/aws-cloudformation-operator@b410313

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).