Closed #486.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#event-272758128
Thanks for the pull request but it's release week in jclouds and that means
it's time to clean up the PR queue. This PR will be over 6 months old as of
April 1. If you intend to continue work on it, please make a comment by April
2. Otherwise it will be closed on April 3.
---
Reply to this emai
To do it right, the auth type should be bounded by the Image capabilities (this
way we'll be able to fail better if an image doesn't have, say, SSH), so I'd:
* Add a `supportedAuthMethods` to the Image object with a default value that
keeps the current behavior.
* In the template options, allow
Yep, that looks much better. It's a bit more complex but better addresses the
issue.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52415441
I agree, both options are bandaids to the real issue: ssh authentication order
not being up to the user. The password being passed back is of no issue if I
can select the authentication method used down the way. The way I am using
Jclouds now is to "direct" jclouds to use a specific authenticati
[jclouds-pull-requests
#1105](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1105/) SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52407575
Ok I see now. So in practice, adding a new method `forceNoPassword` complicates
the usage of the options, but treating the empty strings as a hint to indicate
that no password or private key should be used seems still more obfuscated and
difficult to use.
The main problem here is that the purpo
Hi, please read the commit again, it will make sense now hehe.
The empty password is not provided by nova, but by the user in TemplateOptions
or RunScriptOptions as an override to indicate that we want to set the
password/privatekey to null even if the provider supplies it.
Second, a user might
[jclouds-pull-requests-java-6
#16](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests-java-6/16/)
SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52406139
> if (credsFromParameters.getOptionalPrivateKey().isPresent())
> -
> builder.privateKey(credsFromParameters.getOptionalPrivateKey().get());
> +if (credsFromParameters.getOptionalPassword().get().isEmpty())
Yes, made a small mistake, the second builder.noPassword()
Thanks for the update @wernerb! Just a couple questions:
* Is the "empty password" the *real* password? I mean, is it valid and usable
or is it just something Nova returns "by default"? Would it make sense that
jclouds returned `null` instead of empty in that case?
* If the empty returned passwo
> if (credsFromParameters.getOptionalPrivateKey().isPresent())
> -
> builder.privateKey(credsFromParameters.getOptionalPrivateKey().get());
> +if (credsFromParameters.getOptionalPassword().get().isEmpty())
Also, is it OK to *don't* set the private key if the passw
> if (credsFromParameters.getOptionalPrivateKey().isPresent())
> -
> builder.privateKey(credsFromParameters.getOptionalPrivateKey().get());
> +if (credsFromParameters.getOptionalPassword().get().isEmpty())
This could throw a NPE if the optional password is not pre
[jclouds-pull-requests
#1104](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1104/) SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52394259
[jclouds » jclouds
#1531](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1531/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomme
[jclouds-pull-requests-java-6
#15](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests-java-6/15/)
SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52392588
Instead of adding a new value, it now checks if the password or privatekey is
empty. If so, it will force the password/privatekey to be absent.
Setting an empty password with ssh is a big security red flag anyway and sshd
has it disabled by default. If anyone wants different override behaviour to
[jclouds » jclouds
#1526](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1526/) ABORTED
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52235153
As per Ignasi's [comment in
JIRA](https://issues.apache.org/jira/browse/JCLOUDS-670?focusedCommentId=14097293&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14097293):
still need to test whether this is actually needed...
---
Reply to this email directly or view it
[jclouds-pull-requests-java-6
#11](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests-java-6/11/)
SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-52218561
Adds the option to override whatever password is given from the provider for
the image.
See [jira](https://issues.apache.org/jira/browse/JCLOUDS-670)
You can merge this Pull Request by running:
git pull https://github.com/wernerb/jclouds forcenopassword
Or you can view, comment on it, or merg
21 matches
Mail list logo
