kubernetes/kops

cannot apply changes to Subnet: *gcetasks.Subnet

Opened this issue · 3 comments

0x4d6165 commented

/kind bug

1. What kops version are you running? The command kops version, will display
this information. Client version: 1.28.3 (git-1.28.3)

2. What Kubernetes version are you running? kubectl version will print the
version if a cluster is running or provide the Kubernetes version specified as
a kops flag. Client version: 1.28.3 (git-1.28.3)

3. What cloud provider are you using? GCE

4. What commands did you run? What is the simplest way to reproduce this issue?
Followed the GCE install instructions exactly

5. What happened after the commands executed?
``
wanderingwires-k8s-local" (7m12s remaining to succeed): cannot apply changes to Subnet: *gcetasks.Subnet {"Name":null,"Lifecycle":"","Network":null,"Region":null,"CIDR":"10.0.32.0/20","StackType":null,"Ipv6AccessType":null,"SecondaryIpRanges":null,"Shared":null}
I0128 07:37:30.886241 51637 executor.go:155] No progress made, sleeping before retrying 1 task(s)


**6. What did you expect to happen?**
The Cluster gets created.

**7. Please provide your cluster manifest. Execute
  `kops get --name my.example.com -o yaml` to display your cluster manifest.
  You may want to remove your cluster name and other sensitive information.**

```yaml

8. Please run the commands with most verbose logging by adding the -v 10 flag.
Paste the logs into this report, or in a gist and provide the gist link here.
https://gist.github.com/0x4d6165/8c33c28049d6def56b920dd93b8a62d8

9. Anything else do we need to know?

MaxiBoether commented

I am facing the same issue. Have you found a solution?

sl1pm4t commented

Sounds like the subnet already exists, with a CIDR range that does not match what kOps is trying to set.
You could manually cleanup the existing subnet (if not in use) and try again?

k8s-triage-robot commented

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

This bot triages un-triaged 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:

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

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

/lifecycle stale