> return template =
> addRunScriptToTemplate(buildTemplate(client.templateBuilder()));
> }
>
> - protected static Template addRunScriptToTemplate(Template template) {
> + protected Template addRunScriptToTemplate(Template template) {
>
> template.getOptions().runScript(Statements.newStatementList(AdminAccess.standard(),
> InstallJDK.fromOpenJDK()));
This has been spotted during the Azure ARM development. The scripts work fine,
*but* when a node starts for the first time, Azure installs some extensions and
that uses APT in Debian based distros. APT does not allow concurrent
executions, and the jclouds script fails. This just happens because when
jclouds finds the port 22 open, it immediately runs the script, but Azure is
still installing the extensions.
To mitigate that, we allow providers to override how the script is build, so
they can inject logic bypass these kind of things, while preserving the purpose
of the test. In the current Azure PR they're using this to add a "sleep 50",
but that will be replaced by [this commit I have on a branch in my
fork](https://github.com/nacx/jclouds/commit/2860ec9aff5e4f009946a78fe8f64446456bbdd5),
that would allow to effectively wait until the APT lock is gone with something
like `ScriptBuilder.waitForLockFile("/var/lib/dpkg/lock", 100)`. I'm waiting to
open the PR until I have confirmation that the commit properly fixes the APT
lock issue.
So, long story short, the jclouds scripts are OK and should work in most cases.
However, we've identified this particular case in which the jclouds execution
has to wait a bit more depending on the status of the node, so I nade these
methods protected to let the scripts be customized.
---
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/977/files/d197a9e0cb46888ecc3d7840c2754f39574d0b52#r68054724
