[
https://issues.apache.org/jira/browse/STORM-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Weathers updated STORM-1056:
---------------------------------
Description:
*Requested feature:* allow configuring the supervisor's log filename when
launching it via an ENV variable.
*Motivation:* The storm-on-mesos project (https://github.com/mesos/storm)
relies on multiple Storm Supervisor processes per worker host, where each
Supervisor is dedicated to a particular topology. This is part of the
framework's functionality of separating topologies from each other. i.e.,
storm-on-mesos is a multi-tenant system. But before the change requested in
this issue, the logs from all supervisors on a worker host will be written into
a supervisor log with a single name of supervisor.log. If all logs are written
to a common location on the mesos host, then all logs go to the same log file.
Instead it would be desirable to separate the supervisor logs per-topology, so
that each tenant/topology-owner can peruse the logs that are related to their
own topology. Thus this ticket is requesting the ability to configure the
supervisor log via an environment variable whilst invoking bin/storm.py (or
bin/storm in pre-0.10 storm releases).
When this ticket is fixed, we will include the topology ID into the supervisor
log filename for storm-on-mesos.
was:
Requested feature: allow configuring the supervisor's log filename when
launching it via an ENV variable.
Motivation: The storm-on-mesos project (https://github.com/mesos/storm) relies
on multiple Storm Supervisor processes per worker host, where each Supervisor
is dedicated to a particular topology. This is part of the framework's
functionality of separating topologies from each other. i.e., storm-on-mesos
is a multi-tenant system. But before the change requested in this issue, the
logs from all supervisors on a worker host will be written into a supervisor
log with a single name of supervisor.log. If all logs are written to a common
location on the mesos host, then all logs go to the same log file. Instead it
would be desirable to separate the supervisor logs per-topology, so that each
tenant/topology-owner can peruse the logs that are related to their own
topology. Thus this ticket is requesting the ability to configure the
supervisor log via an environment variable whilst invoking bin/storm.py (or
bin/storm in pre-0.10 storm releases).
When this ticket is fixed, we will include the topology ID into the supervisor
log filename for storm-on-mesos.
> allow supervisor log filename to be configurable via ENV variable
> -----------------------------------------------------------------
>
> Key: STORM-1056
> URL: https://issues.apache.org/jira/browse/STORM-1056
> Project: Apache Storm
> Issue Type: Task
> Reporter: Erik Weathers
> Priority: Minor
> Fix For: 0.10.0, 0.11.0, 0.9.6
>
>
> *Requested feature:* allow configuring the supervisor's log filename when
> launching it via an ENV variable.
> *Motivation:* The storm-on-mesos project (https://github.com/mesos/storm)
> relies on multiple Storm Supervisor processes per worker host, where each
> Supervisor is dedicated to a particular topology. This is part of the
> framework's functionality of separating topologies from each other. i.e.,
> storm-on-mesos is a multi-tenant system. But before the change requested in
> this issue, the logs from all supervisors on a worker host will be written
> into a supervisor log with a single name of supervisor.log. If all logs are
> written to a common location on the mesos host, then all logs go to the same
> log file. Instead it would be desirable to separate the supervisor logs
> per-topology, so that each tenant/topology-owner can peruse the logs that are
> related to their own topology. Thus this ticket is requesting the ability to
> configure the supervisor log via an environment variable whilst invoking
> bin/storm.py (or bin/storm in pre-0.10 storm releases).
> When this ticket is fixed, we will include the topology ID into the
> supervisor log filename for storm-on-mesos.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
