cluster-api-provider-aws

cluster-api-provider-aws copied to clipboard

/kind bug

What steps did you take and what happened:

1. Boot a cluster with a given name in the default namespace
2. Wait for that cluster to successfully come up
3. Create a new namespace
4. Boot a cluster with an identical name to the first in the new namespace
5. Cluster does not create a new VPC or any associated resources

What did you expect to happen: A new VPC, set of machines, and associated resources should have been booted

Anything else you would like to add:

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

The cluster name needs to be unique per <AWS account, region>.

Currently we treat the cluster name as a unique value. We have a few options here:

• Add some type of validation that the cluster name is indeed unique
  • This would still present issues where the controllers are scoped to a single namespace or running under different management clusters
• Prefix everywhere we use the cluster name for naming, tagging, etc with the namespace name
  • This would still present issues where multiple management clusters are in use
  • This could also lead to exceeding string lengths in various places and would need to be accounted for.
• Generate some type of unique identifier that can be pre/post pended to the cluster name
  • This unique identifier would need to be generated and saved to the spec to persist across pivot or a backup/restore (resource UUID does not persist, nor does Status)
  • string lengths should also be accounted for
  • may need to also tag resources with the namespace to help for easier identification of resources in AWS, or some other method to easily differentiate between clusters if running on a single management cluster.

@ncdc that limitation only exists because of the current design, but we do need to have a unique "cluster name" that we set that is used for the integrated or external cloud-provider integration.

@detiber which is still per account+region, unless I'm mistaken?

@ncdc correct

I really like the 3rd option @detiber suggested, which might be part of a larger naming refactor. AWS resources are notoriously limited in how many chars they can use, it'd be great if we could come up with a consistent naming scheme that can be used across all resources and solve this issue as well.

/priority important-soon /milestone v0.4

/assign /lifecycle active

/remove-lifecycle active

Going through open unassigned issues in the v0.5.0 milestone. We have a decent amount of work left to do on CAPI features (control plane, clusterctl, etc). While this is an unfortunately ugly bug, I think we need to defer it to v0.5.

/milestone Next /remove-priority important-soon /priority important-longterm

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

/lifecycle frozen

/remove-lifecycle frozen

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.