Provisioning reserved instances on packet.net fails when using Terraform

[denverwilliams]

When using Terrafrom to provision reserved instances on packet.net, terraform exits with the below error. However this doesn't appear to have an actual effect on the node creation, as the node gets successfully allocated to us and is available over ssh and in the packet api. The major downfall of this is that the node data in unavailable in the Terraform state, so we are unable to use terraform to destroy the node or output node data like hostnames, ips ect.

Error: Error applying plan:

1 error(s) occurred:

* module.worker.packet_device.workers: 1 error(s) occurred:

* packet_device.workers: json: cannot unmarshal string into Go struct field PortData.bonded of type bool

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

The configuration we are using to set the reserved instance can be found here https://github.com/cncf/cnfs/blob/master/comparison/kubecon18-chained_nf_test/k8s_worker_override.tf#L4

And the full Terraform/Node configuration can be found here https://github.com/crosscloudci/cross-cloud/tree/master/packet

[vielmetti]

The struct that it's complaining about is defined here:

https://github.com/packethost/packngo/blob/master/ports.go#L34

[patrickdevivo]

@t0mk do you have any insight here? From the error it sounds like packngo is trying to unmarshal a string into a boolean, which makes me think the API is potentially returning a string where it should be returning a boolean.

I will try to reproduce in the test cases

[t0mk]

@patrickdevivo I managed to reproduce it with PACKNGO_DEBUG=1 PACKNGO_TEST_FACILITY=nrt1 PACKNGO_TEST_ACTUAL_API=1 go test -v -timeout 20m -run=TestAccPort1E

The cause of this problem is [0].

It seems there were some changes in the API in the ports resources, I should have noticed it, but nrt1 was unavailable when I tried to run the Ports tests last time, and those expensive device types are available only in some datacenters. There might be some other issuse with L2 arising from differences in packngo and the API. I will review the state of the L2 in packngo once [0] is fixed, there is no point doing it before.

[0] API bug: https://github.com/packethost/packngo/issues/117

[patrickdevivo]

This has been fixed on the Packet API side FYI

[denverwilliams]

@patrickdevivo Thanks!, Closing.