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:
(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).
(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?
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?