When you created the node, did you also populate it with whatever attributes your search will later use?
I've run into your problem, too, several times, actually - I'm sure it's common.
For instance, I'm using bacula as a backup solution. The bacula director (server) needs to know about all of the clients, and all of the clients need to know about the director.
So when the clients search for the director, there is a chance they don't find one (yet), and similarly, the director may not (yet) find any clients. Both would lead to errors in the bacula configuration. The system won't be stable until it has run twice.
I don't look as the solution as a "hack" but rather as necessary error handling.
There is one other option: instead of a search, you can use a data bag (or even an attribute) to explicitly store the information you would otherwise get from a search. I use this approach in situations where I may have multiple similar servers, and want to be explicitly in which one gets used - for instance, to control which database is stored on which MySQL server.
Kevin Keane
The NetTech
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Douglas Garstang < >
Sent: Saturday 13th June 2015 14:03
To:
Subject: [chef] Re: RE: Chef Search for Node Discovery.Kevin,My boot process runs a script that calls a knife node add, to add the node to chef. Since it's been added to chef, it should be discoverable. However, it's not discoverable until the client has run at least once. That seems more like an architectural problem with chef, rather than a fundamental flaw in the universe. :)What prevents me from doing a two pass run is that I would have to take a process that works fine, and add a hack to make it work when a chef search is required. Every node would have to run twice, or I would have to create some criteria, maybe have CloudFormation put a 'needs-chef-hack' EC2 tag on the instance, and then my scripts check for that. This really isn't very elegant.What if I modified my boot scripts to run chef twice. The first run would essentially be to call a dummy cookbook that does nothing. After this has run, the node would be discoverable? Plenty of other folks must have this same issue.Doug.On Sat, Jun 13, 2015 at 1:43 PM, Kevin Keane Subscription < " target="_blank" title="This external link will open in a new window"> > wrote:It seems to me that this problem is fundamental, not specific to chef: you simply can't discover anything until it is discoverable. Making something discoverable in an automated fashion can happen only by running *something*. In chef, it's chef itself. The other option is to have a separate pre-registration process that pre-creates (and pre-populates) the nodes.
That is also quite possible in chef; you'd use knife (possibly from a shell script) to automatically create your nodes.
But in the end, that doesn't really solve your problem, it just moves it.
Kevin Keane
The NetTech
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Douglas Garstang < " target="_blank" title="This external link will open in a new window"> >
Sent: Friday 12th June 2015 22:01
To: " target="_blank" title="This external link will open in a new window">
Subject: [chef] Chef Search for Node Discovery.I haven't tried this for a while, so I thought I'd see if there was any progress.I need to write a cookbook that discovers other chef nodes. The issue with chef search is that nodes don't report in until they've done their first chef client run, which means that the client has to run twice on the one doing the discovering, but... that also applies to the one that wants to be discovered. End result, not automated. This has basically made chef search unusable in every situation for me where it might otherwise be useful.Is there a better way? I'm on EC2. My other option was to write an ohai plugin to scan ec2 and return instances matching the correct criteria.Thanks,Doug
--Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank" title="This external link will open in a new window">
Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.