Paths as native attributes in chef or ohai?


#1

One thing I love about Chef is that it shines a light on long-standing
issues in systems management that the community has historically ignored
because our environments are often very different. By holding out the
promise of a cross-platform, multi-environment abstraction layer, Chef gets
us thinking about ways to make things better.

The number one issue I run into when using a cookbook written for and
tested on platform X on platform Y is that X and Y don’t keep userland
binaries/libs/configuration files in the same places/paths. Despite all
our efforts to make cookbooks data/attribute driven, we still hard-code
paths all over the place.

Here’s my attempt at a remedy for this:

With some more work, this cookbook can be highly intelligent about setting
paths (like looking at package manager configs to figure out our default
prefix/path for packages).

Is this something that we want in ohai/chef rather than a cookbook? Do we
want to encourage the community at large to use attribute-driven pathing?
(I think we do).

Blake


#2

On Thu, Sep 12, 2013 at 8:59 PM, Blake Irvin blake@wanelo.com wrote:

Is this something that we want in ohai/chef rather than a cookbook? Do we
want to encourage the community at large to use attribute-driven pathing?
(I think we do).

Yes, in both cases! I wholeheartedly agree.

Being able to query the node for path attributes as opposed to having
case statements in each cookbook will be a huge step forward towards
portable cookbooks. Not everything will be covered, of course, (there
are still platform-specific differences to ntp, for example, that
would still need to be covered in the ntp cookbook) but integrating
path determination in Ohai would really help make the vast majority of
cookbooks more portable.

  • Dimitri

#3

On 2013-09-12, at 18:59, Blake Irvin blake@wanelo.com wrote:

One thing I love about Chef is that it shines a light on long-standing issues in systems management that the community has historically ignored because our environments are often very different. By holding out the promise of a cross-platform, multi-environment abstraction layer, Chef gets us thinking about ways to make things better.

The number one issue I run into when using a cookbook written for and tested on platform X on platform Y is that X and Y don’t keep userland binaries/libs/configuration files in the same places/paths. Despite all our efforts to make cookbooks data/attribute driven, we still hard-code paths all over the place.

Here’s my attempt at a remedy for this: https://github.com/wanelo-chef/paths

With some more work, this cookbook can be highly intelligent about setting paths (like looking at package manager configs to figure out our default prefix/path for packages).

Is this something that we want in ohai/chef rather than a cookbook? Do we want to encourage the community at large to use attribute-driven pathing? (I think we do).

I personally standardize on the gnu coding standard/autotools names:

localstatedir: '/var',
sysconfdir: '/etc',
prefix = '/usr/local'
bindir = prefix + '/bin'
libdir = prefix + '/lib'

I only do it because I don’t want to bikeshed, and we shall never break free of autotools.

Your implementation seems very reasonable. I wish we could actually use Pathname objects instead of strings, but the file resources don’t actually support pathnames (due to some string munging deep inside).

~j


#4

Thanks everybody for the feedback.

Maybe the question I really need to ask is, "does anyone not think we
should move towards attribute-driven pathing? I want to get a feel for
community leaning before I put more effort into this cookbook and
refactoring others/submitting pull requests, etc.

Blake

On Tue, Sep 17, 2013 at 5:01 PM, Joseph Holsten joseph@josephholsten.comwrote:

On 2013-09-12, at 18:59, Blake Irvin blake@wanelo.com wrote:

One thing I love about Chef is that it shines a light on long-standing
issues in systems management that the community has historically ignored
because our environments are often very different. By holding out the
promise of a cross-platform, multi-environment abstraction layer, Chef gets
us thinking about ways to make things better.

The number one issue I run into when using a cookbook written for and
tested on platform X on platform Y is that X and Y don’t keep userland
binaries/libs/configuration files in the same places/paths. Despite all
our efforts to make cookbooks data/attribute driven, we still hard-code
paths all over the place.

Here’s my attempt at a remedy for this:
https://github.com/wanelo-chef/paths

With some more work, this cookbook can be highly intelligent about
setting paths (like looking at package manager configs to figure out our
default prefix/path for packages).

Is this something that we want in ohai/chef rather than a cookbook? Do
we want to encourage the community at large to use attribute-driven
pathing? (I think we do).

I personally standardize on the gnu coding standard/autotools names:

localstatedir: '/var',
sysconfdir: '/etc',
prefix = '/usr/local'
bindir = prefix + '/bin'
libdir = prefix + '/lib'

I only do it because I don’t want to bikeshed, and we shall never break
free of autotools.

Your implementation seems very reasonable. I wish we could actually use
Pathname objects instead of strings, but the file resources don’t actually
support pathnames (due to some string munging deep inside).

~j