[
https://issues.apache.org/jira/browse/BIGTOP-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375555#comment-14375555
]
Michael Weiser commented on BIGTOP-1746:
----------------------------------------
[~vishnu]: I've had a quick glance at the patch. This looks like awesome stuff!
Unfortunately I won't have time to try it out this week but I'll test it ASAP.
Sorry as well for not making my patches available but they don't seem to
overlap with what you've done anyway. A couple of quick questions before I dive
into it deeper:
Am I right in assuming that you tried to retain compatibility with the current
components concept? Have you thought about being more radical and dropping
components support in favour of perhaps a couple of template $fqdn.yamls that
implement the same thing? I think this would be awesome in terms of code
cleanup and should be just as easily integrateable with vagrant and other
frameworks: Instead of setting bigtop::hadoop_head_node in site.yaml one just
copies the appropriate template to head.node.do.main.yaml. I think we can be
radical here since with the introduction of hiera the interface changed
substantially quite recently anyway.
Why have you decided on a two-level role layout like zookeeper subrole client?
Couldn't we just direcly include hadoop-zookeeper::client from $roles_map or
directly from hiera?
Without the two-level roles, would we still need the deploy subclasses in each
module? They mostly seem like 1:1 redirections to me. The only exception in
gridgain, which IMO was mistakenly made a defined type and could without
fallout be changed into an includeable class.
Minor niggle: If the main class is (correctly) called bigtop_util, the
directory should be bigtop_util as well.
[~evans_ye]: With hiera we have get away from thinking in terms of one
configuration file. Since hiera is a configuration database with a configurable
lookup path, you can do stuff like I've sketched out in [#comment-14354586]. So
in stead of doing a role mapping in site.yaml, we can just do role assignments
in node-specific node.do.main.yamls.
> Introduce the concept of roles in bigtop cluster deployment
> -----------------------------------------------------------
>
> Key: BIGTOP-1746
> URL: https://issues.apache.org/jira/browse/BIGTOP-1746
> Project: Bigtop
> Issue Type: New Feature
> Components: deployment
> Affects Versions: 0.8.0
> Reporter: vishnu gajendran
> Assignee: vishnu gajendran
> Labels: features
> Fix For: 1.0.0
>
> Attachments: BIGTOP-1746.patch
>
>
> Currently, during cluster deployment, puppet categorizes nodes as head_node,
> worker_nodes, gateway_nodes, standy_node based on user specified info. This
> functionality gives user control over picking up a particular node as
> head_node, standy_node, gateway_node and rest others as worker_nodes. But, I
> woulld like to have more fine-grained control on which deamons should run on
> which node. For example, I do not want to run namenode, datanode on the same
> node. This functionality can be introduced with the concept of roles. Each
> node can be assigned a set of role. For example, Node A can be assigned
> ["namenode", "resourcemanager"] roles. Node B can be assigned ["datanode",
> "nodemanager"] and Node C can be assigned ["nodemanager", "hadoop-client"].
> Now, each node will only run the specified daemons. Prerequisite for this
> kind of deployment is that each node should be given the necessary
> configurations that it needs to know. For example, each datanode should know
> which is the namenode etc... This functionality will allow users to customize
> the cluster deployment according to their needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
