Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add additional checks for instance ssh key conditional #70

Closed
2 tasks done
kral2 opened this issue Sep 9, 2021 · 4 comments · Fixed by #73
Closed
2 tasks done

add additional checks for instance ssh key conditional #70

kral2 opened this issue Sep 9, 2021 · 4 comments · Fixed by #73
Assignees
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Milestone

Comments

@kral2
Copy link
Contributor

kral2 commented Sep 9, 2021

From discussion Originally posted by @calorbeer in #67 (comment)

There is an issue with ssh_public_key variables having default value set to null.

If var.ssh_public_key value is set by the user, ssh_authorized_keys argument is set correctly however if it's null the condition is also evaluated to true and as a result it is set to null. The file statements are never reached. To avoid this the variables either need to default to "" or the conditions have to test for != null and "".

To do:

  • test should be done uppon null and we also initialize relavant variables to null
  • rename ssh_public_key_path to ssh_public_keys_file (plural form for keys and mention file explicitely)
@kral2 kral2 added the bug Something isn't working label Sep 9, 2021
@kral2 kral2 added good first issue Good for newcomers help wanted Extra attention is needed labels Sep 9, 2021
@kral2
Copy link
Contributor Author

kral2 commented Sep 9, 2021

@calorbeer Would you be volunteer to fix that? :-)

For the implementation details, I suggest that the test should be done uppon null and we also initialize relavant variables to null. "" is an empty string: that would make the connection impossible, but it becomes a deliberate choice from the module user.

Let's keep the conditional as simple as possible.

@kral2 kral2 changed the title add additional checks for ss_public_key conditions add additional checks for ssh_public_key conditional Sep 9, 2021
@calorbeer
Copy link

Yes to check for null should be sufficient.

@kral2 kral2 added this to the Future milestone Sep 10, 2021
@kral2 kral2 changed the title add additional checks for ssh_public_key conditional add additional checks for instance ssh key conditional Sep 17, 2021
@kral2
Copy link
Contributor Author

kral2 commented Sep 17, 2021

Based on a review comment that appeared in PR #71, we should also adapt the variable names to be semantically correct: using plural form.

rename ssh_public_key_path to ssh_public_keys_path

For ssh_public_key, we need to figure out if there is possibility to pass multiple ssh keys as string or array of strings.

@kral2 kral2 self-assigned this Sep 17, 2021
kral2 added a commit to kral2/terraform-oci-compute-instance that referenced this issue Sep 17, 2021
…file

This change simplify how ssh_authorized_keys is handled and support more scenarios.
The module input variable now expect a string. It gives more flexibility to the module user
to construct the string as needed: heredoc, file function ...

Fix oracle-terraform-modules#70
@kral2
Copy link
Contributor Author

kral2 commented Sep 17, 2021

Sometimes, less is more :-)

All the use cases can be handled by only one variable: ssh_public_keys (Changing to plural form regarding fc66206).

This greatly simplify the code in the module, and will be probably less confusing for the user.

resource "oci_core_compute" "my_instance" {
...
  metadata = {
    ssh_authorized_keys = var.ssh_public_keys != null ? var.ssh_public_keys : file(var.ssh_authorized_keys)
    user_data           = var.user_data
  }
...
}

The conditional is here only for backward compatibility with var.ssh_authorized_keys. As soon as we move to the next major release, we can drop the conditional all together and adopt this simpler form:

resource "oci_core_compute" "my_instance" {
...
metadata = {
    ssh_authorized_keys = var.ssh_public_keys
    user_data           = var.user_data
  }
...
}

The module user will assign value to this argument like this:

module "my_instance" {
...
  ssh_public_keys = var.my_public_ssh_key
...
}

To provide multiple keys at once, just use Heredoc strings:

module "my_instance" {
...
  ssh_public_keys = <<EOF
<public ssh key 1>
<public ssh key 2>
<public ssh key n>
EOF
...
}

If the module user prefer to provide keys from a file, that's also possible:

module "my_instance" {
...
  ssh_public_keys = file("/path/to/file")
...
}

@kral2 kral2 closed this as completed in #73 Sep 20, 2021
@kral2 kral2 modified the milestones: Future, v2.2.0 Oct 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants