> @@ -129,14 +129,14 @@ public void testOneRecipe() throws IOException {
> replay(validatorKey);
>
> assertEquals(
> - fn.apply("foo").render(OsFamily.UNIX),
> + fn.apply("foo").render(OsFamily.UNIX).replace("\r\n", "\n"),
Great investigations Zach! As you say, Pems.java seems to be the bad boy here:
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/crypto/Pems.java#L403
I don't think it is a bug in Pems.java, because it will generate the PEM file
with the line terminations according to the OS where it is being run.
The bug is in Chef: basically in chef we are composing a script that will be
uploaded to the node, and in the `render` method we tell the scriptbuilder in
which target OS the script be executed, so it can be properly generated. The
problem is that if we are generating the script in a Windows machine, we are
passing a string literal (the private key in PEM format) with CRLF characters
to be directly appended to a file, and the scriptbuilder does not manipulate
the string provided by the user.
I think the correct approach here would be to slightly modify [these
lines](https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/functions/GroupToBootScript.java?source=cc#L110-111)
so they return an statement that overrides the render method to do the
replacement of the line terminations when rendering to UNIX (rendering to
Windows is still not supported in chef). That statement could be a decorator of
the current `appendFile` that replaces the line terminations after the delegate
statement renders the script fragment. This should also allow us to leave the
tests unchanged.
WDYT?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-chef/pull/5/files#r4905205
