Sprint Feedback

[Clint Byrum]

Excerpts from Tom Haddon's message of Tue Jun 07 02:00:26 -0700 2011:
> On Thu, 2011-06-02 at 10:15 -0700, Clint Byrum wrote:
> > Tom, clearly you've got our attention. Thanks so much for all the
> > feedback. Comments in-line.
> > 
> > Excerpts from Tom Haddon's message of Thu Jun 02 05:02:11 -0700 2011:
> > > Dear Ensemble Team,
> > > 
> > > == Things we like about Puppet ==
> > > 
> > > - Declarative state. This makes it easier to manage services over the
> > > longer term, because you can be assured that systems are configured the
> > > way you've told them to be configured.
> > 
> > I'm interested in people taking a shot at writing a formula with Puppet
> > for this very reason. It may simplify some services in that one won't
> > need to keep track of what has been done, since Puppet is already good
> > at that.
> 
> Do you mean writing a formula with Puppet, or writing a Puppet formula?
> I may be misunderstanding the terminology here, but the former sounds
> like using Puppet to write formulas rather than writing a formula that
> deploys Puppet.


I do mean writing a formula that uses Puppet to enact the configuration
supplied by ensemble.

The way I see it happening is the install hook installs Puppet and the
set of modules that the service needs. The relation hooks then simply
tweak the facts and resources available to the Puppet modules. So when
you relate a database, and ensemble now has user/pass/host/etc. You just
put this in a resource file, and enable the things that need it. Then
run Puppet. Ensemble essentially becomes an event driven exported configs
replacement for Puppet, and orchestration replacement for mcollective.

This isn't really a great idea for a simple service setup, but for complex
services that need to run on one machine but have multiple moving parts
that people have already figured out how to configure using Puppet,
this seems like a great way to leverage Puppet's strengths and still be
able to interact with other non-Puppetized services.