[
https://issues.apache.org/jira/browse/WHIRR-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104162#comment-13104162
]
Chad Metcalf edited comment on WHIRR-385 at 9/14/11 2:01 AM:
-------------------------------------------------------------
As it stands this functionality allows whirr developers to build services with
the standard approach of composing statements. A few Modules and a Manifest or
two and you've got a working service.
In order to do this with configs I think you've mostly got something that will
work.
Getting the modules onto the box is a challenge. I limited it to the git clone
case. If you are going to support other mechanisms you'll have to figure that
out. It all has to go into a default location so puppet will pick it up as part
of the default modulepath or you'll also have to configure puppet to expand its
possible modulepath locations.
Firewall rules I think you'd have to make its own properties. You aren't going
to do it in puppet, you'd have to have a specific module or define and add
that to all the modules. Thats a pain and limits the usefulness to whirr aware
modules. Better to just have
{code}
puppet:httpd.tcp-ports=80,443
puppet:foobar.udp-ports=5300,6000-6200
puppet:foobar.icmp=true
{code}
As for service start order unless you make a single node definition puppet
can't handle service ordering. The current implementation basically includes
classes stand alone.
If you want full puppet functionality you need to do real masterless puppet.
In which case you've got a single git repo/tarball/whatever with all the
modules you need with all the dependencies specified. And a single node
definition which switches on roles.
{code}
node default {
if has_role("ntp") {
include ntp
}
if has_role("postgresql::server") {
include postgresql::server
}
}
{code}
That way the postgresql::service service can specify that it depends on ntp...
Or whatever the case may be. Note that this is much
different then the approach outlined in the attached patch which mirrors the
Chef functionality in WHIRR-49.
In this case has_role would be a custom function that would read a file dropped
by Whirr and decide if the node had the role or not.
{code:title=Possible /etc/whirr/roles}
ntp
postgresql::server
{code}
That would be easy and would be distributed and installed by the
install_puppet.sh so that it would always be
# The right version
# Available
was (Author: metcalfc):
As it stands this functionality allows whirr developers to build services
with the standard approach of composing statements. A few Modules and a
Manifest or two and you've got a working service.
In order to do this with configs I think you've mostly got something that will
work.
Getting the modules onto the box is a challenge. I limited it to the git clone
case. If you are going to support other mechanisms you'll have to figure that
out. It all has to go into a default location so puppet will pick it up as part
of the default modulepath or you'll also have to configure puppet to expand its
possible modulepath locations.
Firewall rules I think you'd have to make its own properties. You aren't going
to do it in puppet, you'd have to have a specific module or define and add
that to all the modules. Thats a pain and limits the usefulness to whirr aware
modules. Better to just have
{code}
puppet:httpd.tcp-ports=80,443
puppet:foobar.udp-ports=5300,6000-6200
puppet:foobar.icmp=true
{code}
As for service start order unless you make a single node definition puppet
can't handle service ordering. The current implementation basically includes
classes stand alone.
If you want full puppet functionality you need to do real masterless puppet.
In which case you've got a single git repo/tarball/whatever with all the
modules you need with all the dependencies specified. And a single node
definition which switches on roles.
{code}
node default {
if has_role("ntp") {
include ntp
}
if has_role("postgresql::server") {
include postgresql::server
}
}
{code}
That way the postgresql::service service can specify that it depends on ntp...
Or whatever the case may be. Note that this is much different then the approach
outlined in the attached patch which mirrors the Chef functionality in WHIRR-49.
> Implement support for using nodeless, 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
> Attachments: WHIRR-385.patch
>
> 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
