Packet Terraform provider does not register (save) next-available reserved instances to the terraform state file

[taylor]

Packet Terraform provider does not register (save) reserved server information to the Terraform state

Upstream: https://github.com/terraform-providers/terraform-provider-packet/issues/133

Terraform version: 0.11.10 Packet provider plugin: 1.2.5

When provisioning Packet servers with Terraform using next-available option for reserved instances the servers are provisioned but no state information is saved. Running terraform again will create a new set of servers. Terraform destroy will say there are zero servers to destroy.

Configuration:

• packet.tf
• variables.tf
• Reserved example override

Reference:

• https://github.com/terraform-providers/terraform-provider-packet
• https://github.com/cncf/cnf-testbed/issues/135#issuecomment-468099405
• https://github.com/cncf/cnf-testbed/issues/135#issuecomment-473207955

[taylor]

Should be fixed in the Packet API. Need to test again -> https://github.com/terraform-providers/terraform-provider-packet/issues/133#issuecomment-482526866

[linkous8]

I was able to validate the reserved instances are being populated into the openstack.tfstate and ansible inventory files. An update is needed to reproduce this, will make a PR for it shortly

Change reserved_override.tf.disabled from:

# Provision L2 Networking 

resource "packet_device" "cnfs" {
  hardware_reservation_id = "next-available"
}

To:

# Provision L2 Networking 

resource "packet_device" "master" {
  hardware_reservation_id = "next-available"
}

resource "packet_device" "worker" {
  hardware_reservation_id = "next-available"
}

However, I was not able to verify the full deployment as one of the openstack recipes experienced a fatal error: RuntimeError: ruby_block[wait for identity endpoint] (openstack-identity::registration line 52) had an error: RuntimeError: Waited 60 seconds for identity endpoint to become ready and will not wait any longer

I can provide more of the standard out to anyone who would like it

[linkous8]

Update: we no longer support 16.04 which is the latest version available for the n2 reserved instances. We need an update from Packet to 18.04 in order to leverage the n2 instances

https://support.packet.com/tickets/STLW-1303-PONQ

[linkous8]

Update: the Ubuntu 18.04 port is complete according to maintainers but there are currently issues deploying it. They're aware of the issues and having their team review

[linkous8]

Update: I'm now able to provision 18.04 reserved instances via terraform but the website ui still gives an error when manually trying to do so. Testing a reserved instance deployment now

[michaelspedersen]

Still seeing the issue with 18.04 on n2.xlarge using both web UI and terraform.

Error: Error applying plan:1 error(s) occurred:

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

* packet_device.workers: ubuntu_18_04 is not a valid operating system for the plan n2.xlarge.x86 and facility ["sjc1"]

@linkous8 Did you change anything other than the override file as mentioned above?

[linkous8]

Nope no changes. I just tested myself via web UI and API and both produced the same issue you got and this wasn't occurring before so I don't think its anything on our end. Do you have a chat/ticket open with packet support yet? If not, I'll reach out

[michaelspedersen]

Alright. No I don't have a ticket open since I wanted to check with you first - I am not able to access the ticket you linked above, so couldn't check what the current status was. If you feel like handling the ticket you are more than welcome. I started a workaround using an existing m2.xlarge (with Intel NIC) and no K8s to get a basic setup running for a few benchmarks to be used at the Kubecon presentation on Thursday.

[linkous8]

Good point, I responded to the old ticket since it was still open. Also CC'd you on it with your slack email, let me know if you didn't get access

[rata]

I've used the "next-available" feature with terraform provider 1.7.2 and it works fine now. As far as I can see, there is no change to be made on packet terraform provider but it was fixed in the Packet API.

To confirm, when using "next-available" I can see that the tfstate file is updated with the reservation id (something like "111-sadasd-2sd") for the instance and no changes are required by terraform on later plans/applies. Furthermore, I couldn't reproduce none of the issues mentioned here, it really seems they are fixed in Packet API now.

[rata]

Thanks! :)