whirr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chad Metcalf (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (WHIRR-385) Implement support for using nodeless, masterless Puppet to provision and run scripts
Date Wed, 14 Sep 2011 02:02:09 GMT

    [ 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

        

Mime
View raw message