[chef-dev] Re: Re: Re: Re: Re: Re: Re: Fwd: How do I know if my application has really been "provisioned"? a suggestion

[Mark Van De Vyver < >]

On Mon, Dec 10, 2012 at 10:22 AM, Peter Donald 
<
 >
 wrote:
> Hi,
>
> On Mon, Dec 10, 2012 at 10:07 AM, Mark Van De Vyver 
> <
 >
> wrote:
>>
>>  Longer term I agree that something like the `ensure{}`
>> suggestion might work to allow one chef-solo/client run to coordinate
>> with another.  Irrespective of whether that other process/Chef-Solo run is
>> on
>> another machine or the same machine.
>
>
> I don't know of a good solution for coordination of chef across multiple
> nodes. We currently use a separate command and control service that
> orchestrates the updating of databags and the kick off of chef-client runs
> where appropriate.

There are good solutions, Condor being one, but they can be resource heavy.

> However I have been watching flock_of_chefs [1] which is
> a really interesting take on the whole deal. I am extremely interested in
> that sort of approach for more choreographed releases rather than
> orchestrated releases. No idea if it will eventuate or it is just an
> experiment but it is an interesting project to watch and the author usually
> writes good stuff.

My sense so far is to regard thoughts like 'this Chef run would be so
much better done in parallel' as a kind of code smell.
Of course not everything can be redesigned the way it should have been
done, so the call for parallel will be a perennial one.

Flock does look interesting, I don't doubt it scratches some itches.
To my mind the only long-term advantage it could offer over Condor/MPI
is its resource profile and ease of use.
Given it is written in Ruby the only way it'll get a resource edge is
to delimit the scope of the problem it addresses.
I can't see it has done that, so I think it'll either: a) come to
constrain its communication pattern scope more aggressively, b)
re-implement Condor/MPI and likely make them look resource-lite (in
the case of Condor) and simple (in the case of MPI).
The high risk of b) means I'd be wary of adding it to any dev environment.

Right now I think Ruote would be the Ruby project to look at and I'd
be interested if Flock aims to address some 'thing' that is missing in
Ruote? Or makes it trivial to do what is tricky in Ruote?
AJ you might have an insight?

Best wishes
Mark


>
> [1] https://github.com/chrisroberts/flock_of_chefs
>
> --
> Cheers,
>
> Peter Donald