If you run the chef client manually and there are no circular dependencies, that can be a good strategy. The one thing to keep in mind is that if you raise an error, none of the attributes you changed will be updated on the chef server (that’s why there is a problem with circular dependencies), and you potentially also are left with a partially configured system until the issue is resolved.
I found that often, a better strategy is to simply skip processing the recipe and allow the chef run to complete. Your Web services related functions won’t work, but everything else on the system should be properly configured.
Kevin Keane
The NetTech
760-721-8339
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Dwayne Forehand dwayne@4handsclapping.com
Sent: Monday 26th January 2015 17:54
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Sharing state across an environment
I think for this situation I should be able to avoid circular dependencies pretty easily. I was planning on just raising an error for no results saying that the web service needs to be installed in the environment before this recipe can be processed.
On Mon, Jan 26, 2015 at 5:26 PM, Kevin Keane Subscription <subscription@kkeane.com mailto:subscription@kkeane.com > wrote:
That looks like the way to do it.
One thing that is easy to overlook is handling the situation when the search returns no results. This will probably happen during the initial setup, before your Web services have completed their respective chef runs. That is a particularly insidious problem if you have recursive dependencies - say, your web services also need to keep track of the clients that use the Web service.
If your recipes simply fail when there are no results, you may get stuck in a deadlock where neither client nor server ever complete their runs.
Kevin Keane
The NetTech
760-721-8339
http://www.4nettech.com http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Dwayne Forehand <dwayne@4handsclapping.com mailto:dwayne@4handsclapping.com >
Sent: Monday 26th January 2015 14:35
To: chef@lists.opscode.com mailto:chef@lists.opscode.com
Subject: [chef] Re: Sharing state across an environment
Welp just found the answer to my first question. Having my recipe search for nodes within my environment that have my web service recipe in their run list looks like it would work.
On Mon, Jan 26, 2015 at 2:03 PM, Dwayne Forehand <dwayne@4handsclapping.com mailto:dwayne@4handsclapping.com > wrote:
I’ve got internal and external webserver roles. In my internal run list I have a recipe for a web service which sets a node attribute with that services end point. I’ve got other web app recipes later in the internal run list that use that web service end point attribute in configuring the web apps. I also have a recipe in the external web server role that wants to discover the end point for that web service, but I’m not sure how to access the other nodes attributes or even if I should.
Is there a way that I can set the web service end point attribute at an environment level and have my recipes access it from there? Is there a better way to handle this need?
Thanks,
Dwayne