ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yusaku Sako (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-11210) Topology information in Flume configuration should be processed automatically
Date Fri, 25 Sep 2015 22:49:05 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Yusaku Sako updated AMBARI-11210:
---------------------------------
    Fix Version/s:     (was: 2.1.2)

> Topology information in Flume configuration should be processed automatically
> -----------------------------------------------------------------------------
>
>                 Key: AMBARI-11210
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11210
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.0
>            Reporter: Erik Bergenholtz
>            Assignee: Emil Anca
>
> In the flume-conf ambari configuration I see that the "content" property contains topology
related information but isn't being handled automatically as part of the topology fix-up phase
of blueprint cluster creation.  Currently, this is accomplished by registering the appropriate
updater for the configuration property in BlueprintConfigurationProcessor.  As part of the
next wave of stack enhancements, this would be moved out of the ambari code and into the stack
definition.
> Below is an example value for flume-conf/content.  Notice the references to the concrete
host name "john.novalocal" in the property value.  The user shouldn't have to specify this
information manually in a config override.  In 2.1 it will be possible to provision a cluster
via the api by specifying host counts instead of host names in the cluster creation template
so it won't even be possible to provide host names in a config override.
> {code}
> "content" : "# Name the components on this agent\na1.sources = src1\na1.sinks = sink1\na1.channels
= c1\n\n# Use a channel which buffers events in memory\na1.channels.c1.type = memory\na1.channels.c1.capacity
= 10000\na1.channels.c1.transactionCapacity = 100\n\n# Configure the source\n# a1.sources.src1.type
= exec\n# a1.sources.src1.command =  tail -f /var/log/ambari-a1/ambari-a1.log\na1.sources.src1.channels
= c1\na1.sources.src1.type = multiport_syslogtcp\na1.sources.src1.host = 0.0.0.0\na1.sources.src1.ports
= 8004\n\n# Configure the sink\na1.sinks.sink1.type = hdfs\na1.sinks.sink1.hdfs.path = hdfs://john.novalocal:8020/tmp/logs/\na1.sinks.sink1.hdfs.filePrefix
= events-\na1.sinks.sink1.hdfs.round = true\na1.sinks.sink1.hdfs.roundValue = 10\na1.sinks.sink1.hdfs.roundUnit
= minute\n\n#a1.sinks.sink1.type = logger\na1.sinks.sink1.channel = c1\n\n# Name the components
on this agent\na2.sources = src2\na2.sinks = sink2\na2.channels = c2\n\n# Use a channel which
buffers events in memory\na2.channels.c2.type = memory\na2.channels.c2.capacity = 10000\na2.channels.c2.transactionCapacity
= 100\n\n# Configure the source\n# a2.sources.src2.type = exec\n# a2.sources.src2.command
=  tail -f /var/log/ambari-a2/ambari-a2.log\na2.sources.src2.channels = c2\na2.sources.src2.type
= multiport_syslogtcp\na2.sources.src2.host = 0.0.0.0\na2.sources.src2.ports = 8003\n\n# Configure
the sink\na2.sinks.sink2.type = hdfs\na2.sinks.sink2.hdfs.path = hdfs://john.novalocal:8020/tmp/logs/\na2.sinks.sink2.hdfs.filePrefix
= events-\na2.sinks.sink2.hdfs.round = true\na2.sinks.sink2.hdfs.roundValue = 10\na2.sinks.sink2.hdfs.roundUnit
= minute\n\n#a2.sinks.sink2.type = logger\na2.sinks.sink2.channel = c2"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message