I've been doing some tests and will continue this week, but here's what I'd do
to focus on the authentication issues and fix the *real* problems:
We should try to make this small code snippet work "out of the box":
```java
ComputeServiceContext ctx = ContextBuilder.newBuilder("google-compute-engine")
.credentials("identity", "credential")
.modules(ImmutableSet.of(new SshjSshClientModule())) //
.buildView(ComputeServiceContext.class);
ComputeService compute = ctx.getComputeService();
TemplateOptions options = compute.templateOptions();
Template template = compute.templateBuilder()
.options(options.runScript("uptime"))
.build();
compute.createNodesInGroup("jclouds-auth", 1);
```
This will try to create a node with the default template, and access it to run
the *uptime* command. Note that **we are not providing any credentials** here.
Ideally, this piece of code should work, but we are now just trying to isolate
the issue, so we can play with the *options* object, and override the login
user, password, private key, etc.
Here is what will be going on, related to the credentials when running that
code:
1. jclouds will list all images and try to find the "default" template, as
defined by [the default template
property](https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/GoogleComputeEngineApiMetadata.java#L65)
(which can be, btw, overridden when creating the context).
2. It will transform every GCE image to the jclouds *Image* domain model using
the [configured Image transformation
function](https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/functions/GoogleComputeEngineImageToImage.java).
3. For each resulting image, jclouds will invoke the
[PopulateDefaultLoginCredentialsForImageStrategy](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/strategy/PopulateDefaultLoginCredentialsForImageStrategy.java)
to set the default credentials to access the image. In GCE, that strategy is
bound to [this
class](https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/strategy/PopulateDefaultLoginCredentialsForImageStrategy.java),
but I'm not sure if it is working as expected. We need to review this
carefully and see if what it does is really needed.
4. With the list of images, it runs the
[TemplateBuilder#build](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/internal/TemplateBuilderImpl.java#L670)
method to select the image to deploy.
5. Now the `compute.createNodesInGroup` method will create an instance of the
selected image, and configure a firewall to open port 22, because we've
configured a `runScript` option that requires that port.
6. Once the node is created, **it stores the node credentials** in an internal
(in-memory by default) credential store to reuse them when needed. The stored
credentials are determined by the
[PrioritizeCredentialsFromTemplate](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/strategy/PrioritizeCredentialsFromTemplate.java)
class, which prioritised the credentials extracted from the TemplateOptions,
in case the user configured them (in GCE this strategy is bound to the
[UseNodeCredentialsButOverrideFromTemplate](https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/strategy/UseNodeCredentialsButOverrideFromTemplate.java)
class). If not, it will default to the ones returned
`NodeAndInitialCredentials` object in the `ComputeServiceAdapter`
implementation.
7. Finally, once the note has started, jclouds will block until the port 22 is
open, and then try to authenticate with the resolved credentials.
I've tried to give an overview of the compute process involving the login
credentials, but I might have missed something. In any case, this should give
enough context to play with the given small code snippet being able to debug
the relevant classes to determine what in the provider current implementation
is not properly aligned with what jclouds expects.
In the end, I think we have to answer the following question:
*Do GCE images have default credentials, or an initial login
user/password/privateKey must be always set?*
If the former is true (I think it's not), then we should be able to populate
those default credentials when listing the images, so they already have the
working credentials set. Users should still able to override them using the
template options.
If credentials must be always configured, then we must make sure the provider
works even if they're not provided:
* We should create default SSH key pairs for the instances, if none has been
set (this is what AWS, DigitalOcean or OpenStackNova do). This is the tricky
part, as we must decide *where* we do this. After listing the images (kind of
what is being done now), or *before* creating the nodes (IMO where it should
be).
* We should respect LoginCredentials configured by users in the template
options.
Taking all this into account we should be able to have a flexible
implementation that works with different combinations of the given code
snippet, and live tests will pass (with some minimal changes, such as
configuring some convenience credentials by overriding the
[BaseComputeServiceLiveTest#buildTemplate](https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseComputeServiceLiveTest.java#L514))
method.
Ok, it's been quite a long answer but wanted to give enough context so you can
get an idea of how it works so we can come up with an implementation we're all
happy with. I'll continue testing the provider this week and trying different
implementation changes, and share keep sharing my progress here. Your input and
thoughts are very welcome!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-google/pull/116#issuecomment-67789965
