Add a --rebalance option

See merge request !6

This lets us rebalance the rings without making any changes to device
weights (useful because often a series of weight changes will result
in rings that need rebalancing).

Bug: T317409

Make the process of creating tmpdir and populating it with rings into
a separate function, so we can call it outside of run_srb.

No functional change in this commit.

Update tests to reflect gradual=0.04

See merge request !5

We're using this in prod, and it makes sense for the tests to reflect
a 4% change not the 2% change we were using when we wrote the tests.

No functional change.

Assign zones to eqiad rows E & F

See merge request mvernon/swift-ring!4

E & F have one subnet per rack (and each rack has its own networking
kit); for now keep to one zone per row, rather than going to one per
rack.

Each zone is currently a DC Row - annotate them thus

We've adjust min_part_hours on ms clusters to 12h, so this is back to a full drain/load taking 12-13 days

Currently, prod rings are only changeable every 24 hours, so at 0.02,
that's 50 days for a change. We are moving towards more like 0.08/0.10
(12.5/10 days), and 0.04 (25 days) is the first step, to check this
remains non-disruptive.

...this avoids the "ring file is obsolete" warning we otherwise get sometimes.

We want to sometimes be able to put the new rings tarball somewhere
other than swiftdir; add an optional CLI argument to do so.

For testing use in pontoon, we need to know about the region and zone
use there.

(production rings got rebalanced somewhat in T303507)

Tests re-run on py{2,3}.

Add a -s/--syslog option to log to syslog not stdout

See merge request mvernon/swift-ring!3

Deployment via tarball

See merge request mvernon/swift-ring!2

As part of deployment, we want an option to log to syslog (and be
silent on stdout in normal operation, so not producing cron-mail).

This doesn't change output when -s is not specified, tested on python
2 and 3.

swift-ring-builder returns 1 (warning) incorrectly in a number of
cases, including a number of unhandled exceptions e.g. because a
builder file cannot be written.

In practice, only with "rebalance" do we need to accept rc 1 for no
change to a ring (swift-ring-builder set_weight that makes no change
still returns 0); so be more restrictive except in that case.

The deployment approach is that a puppetmaster will periodically rsync
new_rings.tar.bz2 from each swift_ring_manager host, and then deploy
it to swift servers as rings.tar.bz2 (with suitable handling to untar
this file into /etc/swift when it changes). The aim is to avoid any
race conditions where e.g. .ring.bz and .builder files are deployed
out of sync with each other.

So deploy_rings() now tars up the .builder and .ring.gz files from
tmpdir, and then renames the tarball into swiftdir (ensuring any
readers will either get entirely the old rings or entirely the new
ones).

We are going to deploy via updating a tarball of all rings (rather
than just coping modified rings around), so rather than just copying
rings into tmpdir as we come to modify them instead copy all the rings
into tmpdir at the point we are creating it (i.e. doing the first
modification).

This means rebalance() will rebalance all rings, not just ones we've
changed, but this is harmless - swift-ring-builder exits 1 and says
its made no changes in this case, and that's OK.

Use a named tuple class for (weight,immediate); no functional change

See merge request mvernon/swift-ring!1

Make the WeightChange class, which is a collections.namedtuple. This
lets us access the weight and immediate members by name, making the
code clearer. It also reduces some confusion in the previous code
where (immediate[,weight]) was used for overrides and
(weight,immediate) was used for desired weight changes (i.e. after
applying those overrides).

This change has been tested against the test suite on both python2 and
python3.

(so we always have spaces round them)

...essentially everything this does needs root privilege (to access
swiftdir), so there's no point thinking about a privsep mode of
operation.

R1705 is 'Unnecessary "else" after "return" (no-else-return), but in
these two cases it is a false positive.

If a previous if has return'd, then we don't need else/elif thereafter.

(this is that ts_{start,end} are unused, and that we use the _get_ring_names() method.)

C0302 - too many lines in a module
W0603 - use of the global statement

I think these are OK in a stand-alone executible.