4/30 Opscode Code Review


#1

I’ve shipped the first release candidate of Chef 0.10.10 to Rubygems.
“gem install chef --pre” for the testing. Please file bugs in JIRA and
we’ll get all of this awesomeness out the door as soon as possible.

A couple folks have asked for an Ohai beta to help with the testing,
so we might do that soon too.

It’s a big Opscode party in Seattle this week with myself and the
majority of the rest of the remote employees here for a few days.
Also, nine more employees started today, wow.

To merge:
CHEF-2744 - “knife role show” NoMethodError for PrettyPrinter
format, --format pp or -Fp
CHEF-3060 - mount provider should ignore trailing slash for network fs_spec
CHEF-3067 - mdadm should support argument to supply a write-intent bitmap
OHAI-361 - SmartOS - remove platform_version set in platform switch
OHAI-336 - Running ohai (and chef-client) on OSX without Java prompts user
OHAI-362 - TUN Adapter breaks Ohai Network
OHAI-322 - ohai ipaddress shows ipv6 address as inet instead of
inet6, which also makes ‘ohai ipaddress’ sometimes default to the ipv6
address
OHAI-354 - Add recognition of Omni-Os in platform solairs

Other:
CHEF-2882 - Insufficient Rick Astley in ‘rake roles’ diagnostic message
Closed - Duplicate
CHEF-3052 - knife node edit will create a new node when the name is changed
Reopened - Use existing confirm method
OHAI-359 - Add pear plugin
Reopened - Add a test
OHAI-274 - Support Ohai on JRuby
Reopened - The JRuby road is arduous, how do we feel about this?
OHAI-340 - Windows node.uptime and node.uptime_seconds
Reopened - Require all the libraries that are used


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#2

On Tue, May 1, 2012 at 4:49 AM, Bryan McLellan btm@opscode.com wrote:

OHAI-274 - Support Ohai on JRuby
Reopened - The JRuby road is arduous, how do we feel about this?

Sorry, I’m new to this list. I’m curious what’s the hiccups with Ohai on
JRuby (apart from fork). I’d be very interested in making chef(client and
server) run on top of JRuby since it makes for easy deployment.

  • Ketan

#3

big, big +1 for better support on jruby, though I have no idea of the
technical challenges

On Tue, May 1, 2012 at 6:13 AM, Ketan Padegaonkar <
ketanpadegaonkar@gmail.com> wrote:

On Tue, May 1, 2012 at 4:49 AM, Bryan McLellan btm@opscode.com wrote:

OHAI-274 - Support Ohai on JRuby
Reopened - The JRuby road is arduous, how do we feel about this?

Sorry, I’m new to this list. I’m curious what’s the hiccups with Ohai on
JRuby (apart from fork). I’d be very interested in making chef(client and
server) run on top of JRuby since it makes for easy deployment.

  • Ketan

#4

Bryan Berry bryan.berry@gmail.com writes:

big, big +1 for better support on jruby, though I have no idea of the
technical challenges

I’d also love to have support for jruby.
I’ve written a cookbook with its LWRP that requires “java” and use a
java SDK.
I’ve been using it nearly a year with jchef-solo.
shef, some commands of knife and some plugins of ohai also work.

The ohai hostname plugin does use fork and fails to set fqdn.
chef doesn’t like it, quick workarounds :

  • shef -j attribute.file.json with a fqdn: “my.fqdn” attribute
  • chef-solo -N my.fqdn

In the past I was running jruby with -J-Djava.net.preferIPv4Stack=true
but it looks it’s not relevant anymore. (was preventing a long delay
during startup)


Laurent


#5

I’m currently heading an effort to create a standalone chef-in-a-jar.
I’m working on making chef-client and chef-solo play nice with jruby as
well as the packaging.

Regards,
Avishai

On 01/05/12 13:52, Laurent Desarmes wrote:

Bryan Berry bryan.berry@gmail.com writes:

big, big +1 for better support on jruby, though I have no idea of the
technical challenges
I’d also love to have support for jruby.
I’ve written a cookbook with its LWRP that requires “java” and use a
java SDK.
I’ve been using it nearly a year with jchef-solo.
shef, some commands of knife and some plugins of ohai also work.

The ohai hostname plugin does use fork and fails to set fqdn.
chef doesn’t like it, quick workarounds :

  • shef -j attribute.file.json with a fqdn: “my.fqdn” attribute
  • chef-solo -N my.fqdn

In the past I was running jruby with -J-Djava.net.preferIPv4Stack=true
but it looks it’s not relevant anymore. (was preventing a long delay
during startup)


#6

On Monday, April 30, 2012 at 10:38 PM, Bryan Berry wrote:

big, big +1 for better support on jruby, though I have no idea of the technical challenges

On Tue, May 1, 2012 at 6:13 AM, Ketan Padegaonkar <ketanpadegaonkar@gmail.com (mailto:ketanpadegaonkar@gmail.com)> wrote:

On Tue, May 1, 2012 at 4:49 AM, Bryan McLellan <btm@opscode.com (mailto:btm@opscode.com)> wrote:

OHAI-274 - Support Ohai on JRuby
Reopened - The JRuby road is arduous, how do we feel about this?

Sorry, I’m new to this list. I’m curious what’s the hiccups with Ohai on JRuby (apart from fork). I’d be very interested in making chef(client and server) run on top of JRuby since it makes for easy deployment.

We’re unlikely to support older JRuby (before C ext support); since we don’t support JRuby at all now, it’s easier for us to assume newer JRuby as support gets added. This comes up with ohai because we switched ohai to use the yajl-ruby gem, which uses the yajl C library. We’d also like to switch Chef to using yajl, but we need to refactor our HTTP API code to make this work, which is why we haven’t done it yet.

The only obvious remaining challenge is for Chef and ohai to shell out in a way compatible with JRuby. We’re in the midst of moving all shell usage in ohai and Chef to use mixlib-shellout, so your best bet would be to add JRuby support there:

  • Ruby 1.9 has Process.spawn, which on MRI provides all of the features that mixlib-shellout requires. Unfortunately, most of these options, such as setting the working directory of the spawned process, are ignored in JRuby’s implementation. If you have the Java chops to fix this, that would be a huge benefit for all JRuby users.

  • You could add a Java backend for mixlib-shellout; your best bet is probably to use the Java ProcessBuilder API via JRuby’s Java bridge.

  • The posix-spawn gem supports all of the features we need and works on JRuby, so you could write a posix-spawn backend for mixlib-shellout. The downside here is that we’d have an “optional” gem which would actually be required for JRuby, but we could create jruby platform gems to work around this.

  • Ketan


Dan DeLeo