Fix ip mapping from guest to terraform

[mjrider]

• only accept the first ip adres per family instead of the last one
  This is a problem which machines with floating ipaddresses

• for ipv6, reject link-local ipadresses, those are auto-generated

fixes #127

[vancluever]

Thanks @mjrider - as mentioned will look at this soon 👍

[mjrider]

needs some more work:

• ipv6_gateway: same filtering as for ipv6_address, filter away local scope addresses
• conflicts with Discovery network interfaces from pci devices instead from Guest information #129 ebcause of changes on the same lines

[vancluever]

Hey @mjrider - so a weird side-effect here: Using a config like this for network:

  network_interface {
    label              = "public"
    ipv4_address       = "172.16.1.150"
    ipv4_prefix_length = 24
    ipv4_gateway       = "172.16.1.1"
  }

With an IP address added local to the machine (ie: ip addr add 172.16.1.151/24 dev eth0) leads to the following in the state:

                            "network_interface.#": "1",
                            "network_interface.0.adapter_type": "",
                            "network_interface.0.ip_address": "",
                            "network_interface.0.ipv4_address": "172.16.1.150",
                            "network_interface.0.ipv4_gateway": "172.16.1.1",
                            "network_interface.0.ipv4_prefix_length": "24",
                            "network_interface.0.ipv6_address": "172.16.1.151",
                            "network_interface.0.ipv6_gateway": "",
                            "network_interface.0.ipv6_prefix_length": "32",
                            "network_interface.0.key": "4000",
                            "network_interface.0.label": "public",
                            "network_interface.0.mac_address": "00:50:56:94:22:d5",
                            "network_interface.0.subnet_mask": "",

Note how 172.16.1.151 wound up as the ipv6_address.

Looks like this might be because how you are checking for an IPv6 address with net.IP - To16 will actually convert an IPv4 address to an IPv6 "address":

[DEBUG] p.To16 == net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xac, 0x10, 0x1, 0x97}

What you can do, however, is check for nil on To4. Check https://play.golang.org/p/cKUjXkswjy for an example.

[mjrider]

this should fix #16

[vancluever]

Hey @mjrider - found another one - this is more just a spurious diff issue, stemming from the normalization of IPv6 addresses:

  ~ vsphere_virtual_machine.foo
      network_interface.0.ipv6_address: "fd00::1" => "fd00::0001"

Can we some code in to make sure this is skipped in TF (ie: through maybe a DiffSuppressFunc or a StateFunc), whatever one you think might be more appropriate here?

[mjrider]

@vancluever i added a DiffSuppressFunc for ipv4 and ipv6 address and gateway

[vancluever]

Hey @mjrider - this fixes the normalization issues on IPv6 addresses - thanks!

Looks like, however, we are still having issues with IPv6 addresses - I added another IPv6 address to the interface (fd00::2/112) and am having the same issue now:

  ~ vsphere_virtual_machine.foo
      network_interface.0.ipv6_address: "fd00::2" => "fd00::0001"

I honestly think that what we will ultimately need to do is separate the guest network info from the network information supplied in Terraform, which is ultimately a configuration specification of sorts (I would have to dig into the API to know 100%). Since re-configuration isn't allowed on regular vSphere anyway, having this set to a ForceNew anyway should not necessarily be out of the realm of possibility, with the guest network information being saved to a purely computed hierarchy that does not cause state drift.

This is a longer term thing though and I while IPv6 is important I'd imagine that there are a lot more people with this issue using IPv4, so I'm going to merge this one now. Maybe if you wanted to pick up something, you could see how we could check config to determine if we should even write an IP address to state :)

Thanks for the contribution!