[
https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom White resolved WHIRR-70.
----------------------------
Assignee: Adrian Cole
Fix Version/s: 0.1.0
Resolution: Fixed
I've just committed this. Thanks Adrian!
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Assignee: Adrian Cole
> Fix For: 0.1.0
>
> Attachments: WHIRR-70.patch, WHIRR-70.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The
> intention of this is to pass in the rsa identity used for ssh authentication
> on the cloud nodes. While this is generally on-disk, users may want to pass
> this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push
> the responsibility for reading files to the user. Instead, I suggest we
> offer methods that accept PEM strings for the public and private keys. That
> way, the user can get their keys from files, remote servers, keystores, or
> anywhere, and we don't have an opinion precluding any of that. Moreover, we
> rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") +
> "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new
> File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home")
> + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they
> are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.