[
https://issues.apache.org/jira/browse/WHIRR-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103831#comment-13103831
]
Chad Metcalf edited comment on WHIRR-385 at 9/13/11 5:53 PM:
-------------------------------------------------------------
Alex, I'll put up a patch later today that I've been working on. I took a
pretty direct path from the WHIRR-49 work and came up with three classes.
{{Module}}, {{Resource}}, and {{Manifest}}. Unlike Chef there isn't always a
single Puppet repository to rule them all. So {{{Module}}} allows a checkout of
a given Puppet Module at a specific git url which goes into a directory on the
MODULEPATH. You can instantiate whatever modules you need. {{{Resource}}} is a
class to {{puppet apply}} an arbitrary Puppet resource. {{Resource}} is used by
{{Manifest}} to apply a class in a module (includes support for parameterized
classes).
I think this approach is certainly a flavor masterless. But might be better
called puppet for whirr as its the whirr way of doing things just using puppet
under the covers instead of bash.
A puppet masterless approach, like the one described in the puppet@loggly
presentation is different. It wouldn't require a bunch of {{Statements}} and
java. Rather given a ball of puppet modules and a default node definition it
would include functionality based on facts and functions (including perhaps a
whirr function like Jordan's {{has_role}}). At that point it would be generic.
The whirr client instantiates puppet node(s) with a tarball/git url and the
rest is done.
was (Author: metcalfc):
Alex, I'll put up a patch later today that I've been working on. I took a
pretty direct path from the WHIRR-49 work and came up with three classes.
{{{Module}}}, {{{Resource}}}, and {{{Manifest}}}. Unlike Chef there isn't
always a single Puppet repository to rule them all. So {{{Module}}} allows a
checkout of a given Puppet Module at a specific git url which goes into a
directory on the MODULEPATH. You can instantiate whatever modules you need.
{{{Resource}}} is a class to {{{puppet apply}}} an arbitrary Puppet resource.
{{{Resource}}} is used by {{{Manifest}}} to apply a class in a module (includes
support for parameterized classes).
I think this approach is certainly a flavor masterless. But might be better
called puppet for whirr as its the whirr way of doing things just using puppet
under the covers instead of bash.
A puppet masterless approach, like the one described in the puppet@loggly
presentation is different. It wouldn't require a bunch of {{{Statements}}} and
java. Rather given a ball of puppet modules and a default node definition it
would include functionality based on facts and functions (including perhaps a
whirr function like Jordan's {{{has_role}}}). At that point it would be
generic. The whirr client instantiates puppet node(s) with a tarball/git url
and the rest is done.
> Implement support for using masterless puppet to provision and run scripts
> --------------------------------------------------------------------------
>
> Key: WHIRR-385
> URL: https://issues.apache.org/jira/browse/WHIRR-385
> Project: Whirr
> Issue Type: New Feature
> Components: new service
> Affects Versions: 0.7.0
> Reporter: Alex Heneveld
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> As a user of Whirr, I'd like to be able to use puppet scripts (manifests,
> modules) from within Whirr to set up machines and clusters, because there are
> a lot of OS-neutral capabilities and a large number of actively maintained
> scripts which I could benefit from.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
