whirr-dev mailing list archives

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

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

Alex Heneveld commented on WHIRR-385:


To recap, and make sure that I'm clear and people are happy with the proposal, we are looking
for something that supports:

(1) *The Simple Case*. We want to be able to define, easily in Whirr, what we want Puppet
to actually do. We've taken to calling these "subroles" and denoting them with the syntax
{{puppet:subrole}} in the Whirr config properties (if there is a better word or syntax, please
suggest). These map on to a specific Puppet class or manifest which we want to be able to
specify in the config properties. (And crucially, they don't require a developer to define
a new {{ClusterActionHandler}}.)

In the simple case, say running the an {{ntp}} module {{init.pp}} manifest, we could just

whirr.instance-templates=1 puppet:ntp

(2) *Manifests and Attributes*. Often it is a specific manifest inside a module we wish to
run, and occasionally a manifest not in a module, and often there are attributes we wish to
define.  To do this, the proposal is to require the subrole to be _defined_ in the config
properties using the syntax {{puppet:subrole=module}}.  For example, the following defines
an NTP server _and_ client on a single machine (leaving aside the question of whether this
is a useful configuration; it's a useful illustration).

LocalNtpServer.ntp_sources="0.pool.ntp.org 1.pool.ntp.org"
whirr.instance-templates=1 puppet:LocalNtpServer+puppet:ntp

(The suggestion is that it is required to define {{puppet:ntp=ntp}} even though it seems redundant,
so that the parser can know that {{ntp}} is a defined puppet subrole (without depending on
the {{instance-templates}}) and will be able to list it e.g. in the CLI tool.)

(3) *Module Paths*. The final big question is where should the puppet code come from.  A suggestion
is that by default, it comes from a property, say {{puppet.modulepath}} which defaults to
{{/etc/puppetlabs/puppet/module}}, and can be overridden.  However it may be further desirable
to define per-subrole paths.  Suggested syntax for this is:


* Can we assume that for a given module we need only copy that module, or should we copy all
modules at a given path (i.e. siblings of the intended module)?
* Should we support declaring a path to a specific module -- e.g. {{/path/to/modules/ntp}}
(if we have to copy all modules at a path this could be a significant time-saver; and I don't
think we want to go down the route of ant file selectors!) ?
* Presumably URLs would be nice, e.g. {{http://}} as well as {{file://}}, and possibly {{git://}}
and/or {{classpath://}} (or {{whirr://}} for classpath) -- thoughts?  If so, would we make
{{;}} the path separator char (ouch)?  Or allow {{xxx.modulepath.somepart}} and {{xxx.modulepath.another}}
and stitch these together?  Or some other strategy?

*High-Level Questions*

Does this sound like the right approach?

Is there useful functionality that we are ruling out with this approach and syntax?  (For
example, are we binding too tightly to modules? How would we point to a site.pp file for example?)

*Specific Comments (to previous comments)*

My hunch is that the node-name approach is less relevant in Whirr, since it's typically creating
new machines for which hostname/DNS is often ignored. But it would be an option to have a
convenience in Whirr for specifying the hostname then using a site.pp/node-centric approach.
Thoughts on value & priority of this?

The {{has_roles}} approach is an interesting alternative. Is it more in keeping with what
whirr- and puppet- users would expect, and simpler for them? Or is it too constraining?

Re firewalls, it seems to me it is okay to expect they are either specified in your puppet
code, or in your whirr config (a la WHIRR-371), and so there isn't a need for a general syntax
for specifying puppet firewall rules inside whirr as part of this task. (If the puppet code
looks at attributes to set up firewalls, you could of course still specify those specific
attributes.) Is this sufficient? Is there any worry that we'd get painful conflicts where
both try to configure them?

> 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


View raw message