[
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:54 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 of masterless. But it 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
