[
https://issues.apache.org/jira/browse/WHIRR-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104554#comment-13104554
]
Adrian Cole commented on WHIRR-385:
-----------------------------------
-1 on section (2) Manifests and Attributes.
As it is, we can have ntp::server and ntp::client properties added with no
conflicts using straight up commons properties syntax based on notes from
14/Sep/11 01:17, this is the same way hadoop properties work today. This was
further confirmed by garret's comment that there is no case where trimming the
module or class from the properties key will conflict (bc they cannot have dots
in them)
Currently, there's no requirement that needs symbolic role names and property
key indirection outside of being able to enumerate available puppet roles from
the cli. Even if we did use this approach, it requires manual configuration in
order to set it up the mappings. This is something I perceive as unnecessary
complexity, and a case where the cure is worse than the problem.
If we wish to support multiple instances of the same manifest (ex. ntp::server)
with separate properties, let's wait for someone to have this requirement, as
it would be a general case (ex. 1 zookeepers but with separate properties
bundles), and it would be its own top-level jira.
-1 on section (3) Module Paths:
I don't see the reason to add multiple module paths per module at this point.
Starting simple and adding advanced functionality when asked is a way to keep
our code and complexity from getting out of control. Like above, there's
nothing in this issue that requires url-handling per artifact (in this case
resource containing our module). If we had this requirement, it would be
something all other services would use and need its own top-level jira.
What we need to do is have a mechanism to push a module path physically to the
host, and at beforeBootstrap reconfigure puppet's module paths default to
include them. Currently, we have mechanisms used in whirr to push tarballs and
Chad has mentioned a git option (which he presumably uses). Let's investigate
re-using these approaches before adding more tangental code to the jira.
WRT: Chad's comment mentioning we need to setup a switch statement in order to
implement nodeless masterless:
+1 looks like the default node implementation detail is easy for us to build at
during beforeBootstrap from the puppet manifests passed in from the user (ex.
Statements.appendFile(path, somethingThatBuildsThis). I'm not sure where the
best place to put this file.
> 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
