brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Valentin Aitken (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-415) GCE Windows provisioning fails with defaults: requires explicit `loginUser: ...`
Date Mon, 19 Dec 2016 10:01:58 GMT


Valentin Aitken commented on BROOKLYN-415:

[~aled.sage] I would say default windows user is cloud specific.
For Azure Compute and GCE Administrator user is disabled and cannot be used.
On the contrary there is no way to tell AWS to use other than the default Administrator user.
I think we should change it somehow to defaults somehow to either Administrator or the current
Apache Brooklyn user.

> GCE Windows provisioning fails with defaults: requires explicit `loginUser: ...`
> --------------------------------------------------------------------------------
>                 Key: BROOKLYN-415
>                 URL:
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Aled Sage
>            Priority: Minor
> With brooklyn 0.11.0-snapshot (jclouds 2.0.0)...
> Provisioning a Windows VM in google-compute-engine (with the default configuration) fails
because it uses the login user "Administrator". It fails to connect over WinRM.
> The workaround is to explicitly supply a different login user, such as:
> {noformat}
> location:
>   google-compute-engine:
>     imageNameRegex: windows-server-2012-r2-.*
>     loginUser: myothername
> services:
> - type:
>   brooklyn.config:
>     ...
> {noformat}
> Note that it automatically sets up WinRM access for whichever user is specified in the
"loginUser" (unless {{userMetadata}} is specified with a pre-existing key {{sysprep-specialize-script-cmd}},
I'd guess).
> It would be good if it defaulted to a loginUser that worked (e.g. if no loginUser is
explicitly specified, then default to "brooklyn" instead of "Administrator").
> Much longer term, it would be even better if there was more consistency with ssh'able
machine: there the loginUser is only for the very first connection; subsequently, it will
create the user defined with the {{user}} config (unless other config disabled that).

This message was sent by Atlassian JIRA

View raw message