[
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:
-------------------------------------
*Summary*
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 say:
{noformat}
whirr.instance-templates=1 puppet:ntp
{noformat}
(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).
{noformat}
puppet:LocalNtpServer=ntp::server
LocalNtpServer.ntp_sources="0.pool.ntp.org 1.pool.ntp.org"
puppet:ntp=ntp
ntp.ntpServerList=127.0.0.1
whirr.instance-templates=1 puppet:LocalNtpServer+puppet:ntp
{noformat}
(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:
{noformat}
puppet:LocalNtpServer.modulepath=/path/to/modules:/another/path/to/modules
{noformat}
* 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
