[chef-dev] Re: Re: Re: Re: Re: Re: MySQL, chef-solo and node.save

Chronological Thread 
  • From: Jay Feldblum < >
  • To: John Vincent < >
  • Cc: Chef Dev < >
  • Subject: [chef-dev] Re: Re: Re: Re: Re: Re: MySQL, chef-solo and node.save
  • Date: Thu, 4 Oct 2012 01:34:47 -0400


I would not necessarily use node.save from chef-client either. Relying on that makes too many assumptions that everything goes right on every chef-client run. But of course this is a distributed system designed to be tolerant of failures and to handle failures well, so making too many assumptions that the chef-client run always succeeds can clash with chef's own assumptions about how your recipes behave.

Another approach might be to rely on the automatic node.save done at the end of every chef-client run automatically, and during the recipe simply adding data to the node attributes to be saved later without actually performing the save. If it's vital that some bit of data be remembered until the next time the node is saved, you can use the file-backed variable technique from earlier. This technique can also be thought of as an analog of a write-ahead log.


On Thu, Oct 4, 2012 at 12:43 AM, John Vincent < " target="_blank"> > wrote:
Good to know I'm not the only one then. FWIW, I was just using these
as examples. The real question is still if anyone has any
objects/ideas about allowing node.save from solo. It would definitely
make recipes more reusable I think.

On Wed, Oct 3, 2012 at 9:16 PM, Peter Donald < "> > wrote:
> Hi,
> On Thu, Oct 4, 2012 at 12:07 PM, John Vincent
> <lusis.org+ "> > wrote:
>> I have a DB server. I have an app server. Under the current Chef model
>> (and the design of the official Opscode cookbooks) is that the node
>> NEEDS the resource, declares the resource. If I need a db created, a
>> migration run or a user created the consumer of that resource (in this
>> case the app server) does that work under its Chef cookbooks. Mind you
>> I'd argue that the creator of that resource should be the DB server.
>> However that's just not possible in the current Chef world. I could
>> use Noah to do the orchestration but even I'd admit it's kludgy. What
>> we essentially are faced with his how to declare a resource on another
>> node from the node that needs it.
> This is how we do it for some of our applications. Let's say we have a
> node that runs a service that provides resources to other
> applications. Say we have a node that runs a message broker that hosts
> topics and queues for other applications. We have N application nodes
> that as part of their converge will publish override attributes that
> declare their requirement for a topic or a queue. The next time the
> broker node converges it uses search to pick up all the resources
> requested by application nodes and then uses that data to drive the
> configuration of the set of queues/topics that the broker hosts. The
> releases is often a multi converge process where we first converge the
> application nodes (so they publish requirements and disable the app
> during an upgrade), converge the resource provider nodes (creating the
> resources and possibly doing migrations), then converge the
> application nodes (bringing them online using the new resources).
> of course we rely fairly heavily on chef server to do this...
> --
> Cheers,
> Peter Donald

Archive powered by MHonArc 2.6.16.