[ 
https://issues.apache.org/jira/browse/WHIRR-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104162#comment-13104162
 ] 

Chad Metcalf commented on WHIRR-385:
------------------------------------

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

        

Reply via email to