ionos-cloud / terraform-provider-ionoscloud

The IonosCloud Terraform provider gives the ability to deploy and configure resources using the IonosCloud APIs.
Mozilla Public License 2.0
34 stars 23 forks source link

unsupported SSH key path with VMs/client side validation for paths/labels #404

Closed hegerdes closed 1 year ago

hegerdes commented 1 year ago

Description

When creating resources with the ionos provider, the provisioning fails when there is a ssh key set with common linux paths. Code Example

resource "ionoscloud_server" "example" {
  name          = var.vm_count
  datacenter_id = data.ionoscloud_datacenter.example.id
  cores         = var.vm_cores
  count         = var.vm_count
  ram           = var.vm_ram
  cpu_family    = var.cpu_family
  ssh_keys = ["~/.ssh/id_rsa.pub"]
  image_name    = var.vm_image
  volume {
    name      = "system"
    size      = var.boot_volume_size
    disk_type = var.boot_volume_type
    bus       = "VIRTIO"
  }
}

Id does not complain on terraform plan but as soon as you hit terraform apply it errors with

│ Error: error for public key ~/.ssh/id_rsa.pub, check if path is correct or key is in correct format
│
│   with ionoscloud_server.example[0],
│   on infa.tf line 26, in resource "ionoscloud_server" "example":
│   26: resource "ionoscloud_server" "example" {
│
╵

Note: Using a public ubuntu image

Expected behavior

Create the vm with the ssh key or return a error while planing. Also support UNIX paths as "~/.ssh/id_rsa.pub"

Environment

Terraform version:

Terraform v1.5.1
on windows_amd64
+ provider registry.terraform.io/hashicorp/random v3.5.1
+ provider registry.terraform.io/ionos-cloud/ionoscloud v6.4.1

Configuration Files

How to Reproduce

Steps to reproduce the behavior:

  1. Create a provider
  2. Create a vm with ssh keys
  3. terraform plan -out plan.out && terraform apply plan.out

Error and Debug Output

Also I got this error. It would be nice if there is more client side validation

│ Error: error occured while creating label for server with ID: b39db529-6ee3-4547-8c6f-8ca6ddf13f80, datacenter ID: 17970bbc-b8be-46af-8425-af9658653509, error: (422 Unprocessable Entity {
│   "httpStatus" : 422,
│   "messages" : [ {
│     "errorCode" : "100",
│     "message" : "[(root).properties.key] Invalid, please provide only lower case alphabets (a-z) or numeric (0-9) characters"
│   } ]
│ }
│ )

Additional Notes

References

cristiGuranIonos commented 1 year ago

Thanks for creating this! The error seems to be from defining a label on the server. For labels we support only lowercase, or numeric characters. An example that wouldn't work because of the uppercase L: label { key = "Labelkey0" value = "labelvalue0" } We will add validation on terraform side to make sure this gets caught before reaching backend.

hegerdes commented 1 year ago

Thanks for the fast reply. And sorry for the inaccurate Issue. I fixed the issue description.

It is in fact a issue with the label name. But I also found that there is also an error with the ssh_keys param.

ssh_keys = ["scripts/id_rsa.pub"] # Works
ssh_keys = ["~/.ssh/id_rsa.pub"] # Does not work

So there is an error with common UNIX path styles

cristiGuranIonos commented 1 year ago

The ~ is something that will get expanded to the user's home dir in bash. If you're using a different shell you can get different behavior. We can mention that we don't support these types of paths. Either a relative or an absolute path should work.

hegerdes commented 1 year ago

The ~ is something that will get expanded to the user's home dir in bash. If you're using a different shell you can get different behavior.

Didn't know different shells handle this differently. Therfore I can understand your decison to not support it (even though it would have been nice to have). But if this is mentioned in the docs this would be perfect!

Thanks for this super fast PR, would you also be so nice to add client side validation for unsupported paths like these? Currently this is also only catched when applying the infra.