cormacrelf / terraform-provider-zerotier

Create, modify and destroy ZeroTier networks and members through Terraform.
128 stars 25 forks source link

Networks being created as new when they already exist #2

Closed andyshinn closed 6 years ago

andyshinn commented 6 years ago

I'm having an issue where sometimes the zerotier_network resource gets created again (it doesn't think it exists). This particular workspace I didn't catch it and I ended up with two for the same name:

-/+ google_compute_route.zerotier-administrator (new resource required)
      id:                                 "zerotier-administrator-a84ac5c10afccff7" => <computed> (forces new resource)
      dest_range:                         "192.168.191.0/24" => "192.168.191.0/24"
      name:                               "zerotier-administrator-a84ac5c10afccff7" => "zerotier-administrator-${zerotier_network.administrator.id}" (forces new resource)
      network:                            "https://www.googleapis.com/compute/v1/projects/default-3aef9459/global/networks/default" => "default"
      next_hop_instance:                  "projects/default-3aef9459/zones/us-east1-d/instances/zerotier" => "zerotier"
      next_hop_instance_zone:             "us-east1-d" => "us-east1-d"
      next_hop_network:                   "" => <computed>
      priority:                           "1500" => "1500"
      project:                            "default-3aef9459" => <computed>
      self_link:                          "https://www.googleapis.com/compute/v1/projects/default-3aef9459/global/routes/zerotier-administrator-a84ac5c10afccff7" => <computed>

+ zerotier_network.administrator
      id:                                 <computed>
      assignment_pool.#:                  "1"
      assignment_pool.2715204528.cidr:    ""
      assignment_pool.2715204528.first:   "192.168.191.10"
      assignment_pool.2715204528.last:    "192.168.191.254"
      auto_assign_v4:                     "true"
      description:                        "Managed by Terraform"
      name:                               "default-3aef9459-administrator"
      private:                            "true"
      route.#:                            "2"
      route.0.target:                     "192.168.191.0/24"
      route.1.target:                     "10.142.0.0/20"
      route.1.via:                        "192.168.191.1"
      rules_source:                       "#\n# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.\n#\ndrop\n\tnot ethertype ipv4\n\tand not ethertype arp\n\tand not ethertype ipv6\n;\n\n#\n# Uncomment to drop non-ZeroTier issued and managed IP addresses.\n#\n# This prevents IP spoofing but also blocks manual IP management at the OS level and\n# bridging unless special rules to exempt certain hosts or traffic are added before\n# this rule.\n#\n#drop\n#\tnot chr ipauth\n#;\n\n# Accept anything else. This is required since default is 'drop'.\naccept;"

I'll try to get state output next time I see this. Unfortunately, I applied this before grabbing state.

Any idea why this might happen?

andyshinn commented 6 years ago

Just a shot int the dark...

It looks like CheckNetworkExists will return false for a non-200 response code or an error: https://github.com/cormacrelf/terraform-provider-zerotier/blob/master/client.go#L185-L197.

According to the Golang http package at https://golang.org/pkg/net/http/#Client:

A non-2xx status code doesn't cause an error.

Would this mean that a temporary error (such as a 5xx) would cause the provider to think that the network doesn't exist?

andyshinn commented 6 years ago

We've also learned this happens on a 403 now. In the case a user doesn't have access to the network (the API returns an access_denied) it tries to create the network. This should likely fail instead (and just let the user know of the permissions issue).

cormacrelf commented 6 years ago

You were right. Latest code fixes it.