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

[John Vincent < >]

On Wed, Oct 3, 2012 at 10:34 PM, Jay Feldblum 
<
 >
 wrote:
> John,
>
> 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.
>

Yeah I'm not a big fan of calling node.save myself. The problem is
that you HAVE to do it in several places. The mysql cookbook is a
really good example. This wasn't an issue until the node.save was
moved to only happening at the end of a successful first run. But in
the case of the mysql cookbook, the problem is that if the initial run
of mysql::server fails, it's impossible (or almost) to recover from.
The install was done with a preseeded randomly generated value for the
passwords on debian clones. There's no way to rerun that cookbook and
have it pick up where it left off if it fails at some point during the
run of the mysql::server recipe unless you save the node attributes
right after you generate that random password.

Mind you, I'm a big proponent of (and performer of) testing FULL
bootstrap after every change. I design where I can for a bootstrap to
bring me fully into service as a given role. The only way to do that
is to know that the bootstrap will never fail when I need it and I can
go right into service when I need it.

> 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.
>
> Cheers,
> Jay
>
>
> On Thu, Oct 4, 2012 at 12:43 AM, John Vincent 
> <
 >
> 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
>> > <
 >
>> >  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
>
>