[jira] [Updated] (AMBARI-11210) Topology information in Flume configuration should be processed automatically

["Nate Cole (JIRA)" <ji...@apache.org>]

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

Nate Cole updated AMBARI-11210:
-------------------------------
    Fix Version/s:     (was: 2.1.1)
                   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
>             Fix For: 2.1.2
>
>
> 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)