I meant Zack :)
On 27 June 2013 00:48, Ignasi Barrera <[email protected]> wrote: >> @@ -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
