def rebalance(*args):
    'Syntax: [storm rebalance topology-name [-w wait-time-secs] [-n new-num-workers] [-e component=parallelism]*  [-r \'{"component1": {"resource1": new_amount, "resource2": new_amount, ... }*}\'] [-t \'{"conf1": newValue, *}\']]\n\n    Sometimes you may wish to spread out the workers for a running topology.\n    For example, let\'s say you have a 10 node cluster running\n    4 workers per node, and then let\'s say you add another 10 nodes to\n    the cluster. You may wish to have Storm spread out the workers for the\n    running topology so that each node runs 2 workers. One way to do this\n    is to kill the topology and resubmit it, but Storm provides a "rebalance"\n    command that provides an easier way to do this.\n\n    Rebalance will first deactivate the topology for the duration of the\n    message timeout (overridable with the -w flag) make requested adjustments to the topology\n    and let the scheduler try to find a better scheduling based off of the\n    new situation. The topology will then return to its previous state of activation\n    (so a deactivated topology will still be deactivated and an activated\n    topology will go back to being activated).\n\n    Some of what you can change about a topology includes the number of requested workers (-n flag)\n    The number of executors for a given component (-e flag) the resources each component is\n    requesting as used by the resource aware scheduler (-r flag) and configs (-t flag).\n    '
    if (not args):
        print_usage(command='rebalance')
        sys.exit(2)
    exec_storm_class('org.apache.storm.command.Rebalance', args=args, jvmtype='-client', extrajars=[USER_CONF_DIR, STORM_BIN_DIR])
Syntax: [storm rebalance topology-name [-w wait-time-secs] [-n new-num-workers] [-e component=parallelism]*  [-r '{"component1": {"resource1": new_amount, "resource2": new_amount, ... }*}'] [-t '{"conf1": newValue, *}']]

Sometimes you may wish to spread out the workers for a running topology.
For example, let's say you have a 10 node cluster running
4 workers per node, and then let's say you add another 10 nodes to
the cluster. You may wish to have Storm spread out the workers for the
running topology so that each node runs 2 workers. One way to do this
is to kill the topology and resubmit it, but Storm provides a "rebalance"
command that provides an easier way to do this.

Rebalance will first deactivate the topology for the duration of the
message timeout (overridable with the -w flag) make requested adjustments to the topology
and let the scheduler try to find a better scheduling based off of the
new situation. The topology will then return to its previous state of activation
(so a deactivated topology will still be deactivated and an activated
topology will go back to being activated).

Some of what you can change about a topology includes the number of requested workers (-n flag)
The number of executors for a given component (-e flag) the resources each component is
requesting as used by the resource aware scheduler (-r flag) and configs (-t flag).
def rebalance(*args):
    'Syntax: [storm rebalance topology-name [-w wait-time-secs] [-n new-num-workers] [-e component=parallelism]*  [-r \'{"component1": {"resource1": new_amount, "resource2": new_amount, ... }*}\'] [-t \'{"conf1": newValue, *}\']]\n\n    Sometimes you may wish to spread out the workers for a running topology.\n    For example, let\'s say you have a 10 node cluster running\n    4 workers per node, and then let\'s say you add another 10 nodes to\n    the cluster. You may wish to have Storm spread out the workers for the\n    running topology so that each node runs 2 workers. One way to do this\n    is to kill the topology and resubmit it, but Storm provides a "rebalance"\n    command that provides an easier way to do this.\n\n    Rebalance will first deactivate the topology for the duration of the\n    message timeout (overridable with the -w flag) make requested adjustments to the topology\n    and let the scheduler try to find a better scheduling based off of the\n    new situation. The topology will then return to its previous state of activation\n    (so a deactivated topology will still be deactivated and an activated\n    topology will go back to being activated).\n\n    Some of what you can change about a topology includes the number of requested workers (-n flag)\n    The number of executors for a given component (-e flag) the resources each component is\n    requesting as used by the resource aware scheduler (-r flag) and configs (-t flag).\n    '
    if (not args):
        print_usage(command='rebalance')
        sys.exit(2)
    exec_storm_class('org.apache.storm.command.Rebalance', args=args, jvmtype='-client', extrajars=[USER_CONF_DIR, STORM_BIN_DIR])