Kevin,Thanks. Unfortunately I could never get handlers to work. I tried several times over a period of several months and eventually gave up. :(Douglas.On Thu, Sep 10, 2015 at 10:27 AM, Kevin Keane Subscription < " target="_blank"> > wrote:I just came across chef start handlers that might do what you need:
https://docs.chef.io/handlers.html
Kevin Keane
The NetTech
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Doug Garstang < " target="_blank"> >
Sent: Wednesday 9th September 2015 2:35
To: " target="_blank">Subject: [chef] Re: RE: Re: RE: Re: Re: Populating attributes from the system.Kevin,Local = local to the node. Our instances configure themselves on boot. It's the only way to go. :) It means any schmuck can start a CloudFormation stack and not have to know anything about the internals of how the instance is configured.Actually it depends on the limitations and features of chef. As I understand it now, executing chef-client and passing in json parameters seems to be the _only_ way to inject attributes into a cookbook before it runs. Ohai plugins can't be accessed during compilation, libraries can't be accessed during compilation. If you need to get info from the system, and derive attributes from it, well, there doesn't seem to be a whole lot of options. There seems to be no way to do it in a cookbook. Unless, I am missing something?Doug.Douglas.On Tue, Sep 8, 2015 at 4:34 PM, Kevin Keane Subscription < " title="This external link will open in a new window" target="_blank"> > wrote:Exactly *how* you do it depends on your specific architecture, so I can't really be of too much help. What I was actually thinking of was to invoke knife to add attributes to the node.
When you say "locally" do you mean, local to the node, or local to the chef workstation?
Kevin Keane
The NetTech
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Doug Garstang < " title="This external link will open in a new window" target="_blank"> >
Sent: Tuesday 8th September 2015 15:26
To: " title="This external link will open in a new window" target="_blank">Subject: [chef] Re: RE: Re: Re: Populating attributes from the system.Kevin,The run list is populated by a script that runs locally and reads a config file. It sounds like your suggesting I convert this config file to json and pass it to the chef-client with -j? Those attributes are immediately available, right?Doug.On Tue, Sep 8, 2015 at 2:47 PM, Kevin Keane Subscription < " title="This external link will open in a new window" target="_blank"> > wrote:I agree that such an application-specific thing is not the best use of Ohai.
How do you populate the node's run list? For the scenario you describe, it seems to me that whatever tool you use to do that should also look for this specific file and either change the run list, or set node attributes based on the settings in this file.
I have a "main" cookbook that handles these types of things. When I bring up a new node, initially only the main cookbook is in the runlist, and it then populates the run list, as well as figures out various attribute settings.
Kevin Keane
The NetTech
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Douglas Garstang < " title="This external link will open in a new window" target="_blank"> >
Sent: Tuesday 8th September 2015 13:09
To: " title="This external link will open in a new window" target="_blank">
Subject: [chef] Re: Re: Populating attributes from the system.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_REGEXOhai just feels less well documented and maintained.Doug.On Tue, Sep 8, 2015 at 1:33 PM, Adam Leff < " title="This external link will open in a new window" target="_blank"> > 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?~AdamOn Tue, Sep 8, 2015 at 4:29 PM Doug Garstang < " title="This external link will open in a new window" target="_blank"> > 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: " title="This external link will open in a new window" target="_blank">
Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.