[chef] RE: Re: RE: Re: Sharing state across an environment


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: RE: Re: Sharing state across an environment
  • Date: Mon, 26 Jan 2015 19:14:11 -0800

Title: RE: [chef] Re: RE: Re: Sharing state across an environment

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

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html


-----Original message-----
From: Dwayne Forehand < >
Sent: Monday 26th January 2015 17:54
To:
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 < " target="_blank" title="This external link will open in a new window"> > 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

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html


-----Original message-----
From: Dwayne Forehand < " target="_blank" title="This external link will open in a new window"> >
Sent: Monday 26th January 2015 14:35
To: " target="_blank" title="This external link will open in a new window">
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 < " target="_blank" title="This external link will open in a new window"> > 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





Archive powered by MHonArc 2.6.16.

§