Populating attributes from the system

This problem keeps popping up, and it never feels quite right.

I need to extract some data from the system and populate node attributes
from that, so that my cookbook will function.

If I use a library to get the system info, then I have move the setting of
the attributes out of attributes/ files into a recipe, and make sure that
recipe runs first. Any attributes that are derived from these attributes
also have to be put into the same recipe. I then have some attributes being
defined in attributes files and some recipes which doesn’t feel right.

Writing an ohai plugin that pulls the system info means that the attributes
are immediately available as ohai data when chef runs. This also feels like
the wrong approach though.

What is the right way to do this?

Doug.

Doug-

If the data you're trying to extract is part of your system and not curated
during a Chef run, I think Ohai is a perfect solution for this. The first
recipe in your nodes' run_lists could also deploy that Ohai plugin and
reload it right away (if it needed to be deployed during that run) such
that the rest of your chef-client run would have immediate access to the
new plugin's data.

Could you elaborate as to why you do not feel the Ohai plugin approach is
the right fit?

~Adam

On Tue, Sep 8, 2015 at 4:29 PM Doug Garstang doug@slice.com wrote:

This problem keeps popping up, and it never feels quite right.

I need to extract some data from the system and populate node attributes
from that, so that my cookbook will function.

If I use a library to get the system info, then I have move the setting of
the attributes out of attributes/ files into a recipe, and make sure that
recipe runs first. Any attributes that are derived from these attributes
also have to be put into the same recipe. I then have some attributes being
defined in attributes files and some recipes which doesn't feel right.

Writing an ohai plugin that pulls the system info means that the
attributes are immediately available as ohai data when chef runs. This also
feels like the wrong approach though.

What is the right way to do this?

Doug.

Adam,

I guess it feels wrong because I'm writing application specific things into
something that's supposed to read to get system info. Our CloudFormation
template is writing a file to the local filesystem that my chef cookbook
needs to be able to read in order to know what branch, release etc of code
to deploy. The custom ohai documentation is pretty slim as well, and it
usually takes me a lot longer to get something working with ohai that it
would a library.

Using the community ohai cookbook and also seeing this:

==> default:
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-7.0.4/lib/ohai/plugins/linux/network.rb:49:
warning: already initialized constant IPROUTE_INT_REGEX

Ohai just feels less well documented and maintained.

Doug.

On Tue, Sep 8, 2015 at 1:33 PM, Adam Leff adam@leff.co wrote:

Doug-

If the data you're trying to extract is part of your system and not
curated during a Chef run, I think Ohai is a perfect solution for this.
The first recipe in your nodes' run_lists could also deploy that Ohai
plugin and reload it right away (if it needed to be deployed during that
run) such that the rest of your chef-client run would have immediate access
to the new plugin's data.

Could you elaborate as to why you do not feel the Ohai plugin approach is
the right fit?

~Adam

On Tue, Sep 8, 2015 at 4:29 PM Doug Garstang doug@slice.com wrote:

This problem keeps popping up, and it never feels quite right.

I need to extract some data from the system and populate node attributes
from that, so that my cookbook will function.

If I use a library to get the system info, then I have move the setting
of the attributes out of attributes/ files into a recipe, and make sure
that recipe runs first. Any attributes that are derived from these
attributes also have to be put into the same recipe. I then have some
attributes being defined in attributes files and some recipes which doesn't
feel right.

Writing an ohai plugin that pulls the system info means that the
attributes are immediately available as ohai data when chef runs. This also
feels like the wrong approach though.

What is the right way to do this?

Doug.

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Adam,

Actually I misspoke earlier. I'd forgotten about this. You can't access
attributes from custom ohai plugins in attributes/ files. This is a pretty
big deal. As far as I can see, there's no way to easily grab custom
information from the system during the (is it the compile?) phase.

This is what I did earlier, and it's pretty ugly.

#attributes/default.rb
def component_info
#ruby code to get system info here
end

(component_name, component_group, release_branch, release_version) =
component_info()

node['webapp']['version'] = release_version

At least I can access that during the compile phase and derive other
attributes from it. Isn't there a better way?

Doug.

On Tue, Sep 8, 2015 at 1:38 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Adam,

I guess it feels wrong because I'm writing application specific things
into something that's supposed to read to get system info. Our
CloudFormation template is writing a file to the local filesystem that my
chef cookbook needs to be able to read in order to know what branch,
release etc of code to deploy. The custom ohai documentation is pretty slim
as well, and it usually takes me a lot longer to get something working with
ohai that it would a library.

Using the community ohai cookbook and also seeing this:

==> default:
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-7.0.4/lib/ohai/plugins/linux/network.rb:49:
warning: already initialized constant IPROUTE_INT_REGEX

Ohai just feels less well documented and maintained.

Doug.

On Tue, Sep 8, 2015 at 1:33 PM, Adam Leff adam@leff.co wrote:

Doug-

If the data you're trying to extract is part of your system and not
curated during a Chef run, I think Ohai is a perfect solution for this.
The first recipe in your nodes' run_lists could also deploy that Ohai
plugin and reload it right away (if it needed to be deployed during that
run) such that the rest of your chef-client run would have immediate access
to the new plugin's data.

Could you elaborate as to why you do not feel the Ohai plugin approach is
the right fit?

~Adam

On Tue, Sep 8, 2015 at 4:29 PM Doug Garstang doug@slice.com wrote:

This problem keeps popping up, and it never feels quite right.

I need to extract some data from the system and populate node attributes
from that, so that my cookbook will function.

If I use a library to get the system info, then I have move the setting
of the attributes out of attributes/ files into a recipe, and make sure
that recipe runs first. Any attributes that are derived from these
attributes also have to be put into the same recipe. I then have some
attributes being defined in attributes files and some recipes which doesn't
feel right.

Writing an ohai plugin that pulls the system info means that the
attributes are immediately available as ohai data when chef runs. This also
feels like the wrong approach though.

What is the right way to do this?

Doug.

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Hi Doug,

If you're looking for better documentation on Ohai, and working with it in
Chef, consider Chapter 4 (Extending Ohai) from the book Customizing Chef (
http://shop.oreilly.com/product/0636920032984.do). The rest of the book is
pretty solid as well.

Best,
Bryant

On Tue, Sep 8, 2015 at 4:02 PM, Doug Garstang doug@slice.com wrote:

Adam,

Actually I misspoke earlier. I'd forgotten about this. You can't access
attributes from custom ohai plugins in attributes/ files. This is a pretty
big deal. As far as I can see, there's no way to easily grab custom
information from the system during the (is it the compile?) phase.

This is what I did earlier, and it's pretty ugly.

#attributes/default.rb
def component_info
#ruby code to get system info here
end

(component_name, component_group, release_branch, release_version) =
component_info()

node['webapp']['version'] = release_version

At least I can access that during the compile phase and derive other
attributes from it. Isn't there a better way?

Doug.

On Tue, Sep 8, 2015 at 1:38 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Adam,

I guess it feels wrong because I'm writing application specific things
into something that's supposed to read to get system info. Our
CloudFormation template is writing a file to the local filesystem that my
chef cookbook needs to be able to read in order to know what branch,
release etc of code to deploy. The custom ohai documentation is pretty slim
as well, and it usually takes me a lot longer to get something working with
ohai that it would a library.

Using the community ohai cookbook and also seeing this:

==> default:
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-7.0.4/lib/ohai/plugins/linux/network.rb:49:
warning: already initialized constant IPROUTE_INT_REGEX

Ohai just feels less well documented and maintained.

Doug.

On Tue, Sep 8, 2015 at 1:33 PM, Adam Leff adam@leff.co wrote:

Doug-

If the data you're trying to extract is part of your system and not
curated during a Chef run, I think Ohai is a perfect solution for this.
The first recipe in your nodes' run_lists could also deploy that Ohai
plugin and reload it right away (if it needed to be deployed during that
run) such that the rest of your chef-client run would have immediate access
to the new plugin's data.

Could you elaborate as to why you do not feel the Ohai plugin approach
is the right fit?

~Adam

On Tue, Sep 8, 2015 at 4:29 PM Doug Garstang doug@slice.com wrote:

This problem keeps popping up, and it never feels quite right.

I need to extract some data from the system and populate node
attributes from that, so that my cookbook will function.

If I use a library to get the system info, then I have move the setting
of the attributes out of attributes/ files into a recipe, and make sure
that recipe runs first. Any attributes that are derived from these
attributes also have to be put into the same recipe. I then have some
attributes being defined in attributes files and some recipes which doesn't
feel right.

Writing an ohai plugin that pulls the system info means that the
attributes are immediately available as ohai data when chef runs. This also
feels like the wrong approach though.

What is the right way to do this?

Doug.

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Bryant Lippert

Raindance

bryant@raindanceit.com

M 302-465-4326