RE: Re: RE: Re: Sharing state across an environment


#1

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 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


#2

Excellent. Thank you Kevin!

On Mon, Jan 26, 2015 at 7:14 PM, Kevin Keane Subscription <
subscription@kkeane.com> wrote:

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 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> 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 dwayne@4handsclapping.com
Sent: Monday 26th January 2015 14:35
To: 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> 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