It's pissing me off.
Good news, there's an interactive interpreter (sometimes called REPL) for chef, named shef. The bad news? Configuring your jenkins instance without trashing the current one is still thorny.
So, imagine you bring up your instance and it's completely live. Tries to process jobs, and do things. Whoops! Shove that thing into quiet mode a couple of times, and disable the master executor.
Also, I set the jenkins package to purge. That was bad. Purge removes the package, but it also does things like delete the jenkins user and nuke the working directory. Don't do that if you want to keep your job configurations and build history.
Also, if you set a pub ssh key on a jenkins user, and it's the same one as your jenkins root user, you will always fail to use the cli jar, so don't do that (jenkins cli steps will try to use the identities found in ~/.ssh, which fails when AD auth is on).
Today is adding slaves day.
It turned out to be only partly lame.
Adding a linux slave to the master with the ssh variant was ok, but the connection keeps not working. It turns out, after burning a day on this, that the jiggery-pokery that is the groovy/rooby serialization/bridge is a house of cards. The ssh-slave's modern version deprecated a key function, and it caused the generation of new useless credentials for the slave, with its name set to the uuid4 of the real key wanted, and a null pointer exception when trying to connect. Because there was no valid credential for the slave to connect with.
One can only hope for some kind of sweet powershell connection to windows in the future (from the jenkins host), because rolling out the windows slave is going to be a brand new recipe / chef install on staging nodes. Good luck wtih that!
Your project homework? Writing a jenkins winrm connector to replace/burn-with-fire the current jenkins windows slave plugin. One could also probably make cash by integrating the chef REPL model into a gui debugger with full-ruby-chef-stack support.
Leave a comment