[jira] [Issue Comment Edited] (WHIRR-385) Implement support for using nodeless, masterless Puppet to provision and run scripts

["Chad Metcalf (JIRA)" <ji...@apache.org>]

    [ 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