Reviewed:  https://review.openstack.org/257416
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=b38681f64613ff976b8f1137fad0a7dd28e27410
Submitter: Jenkins
Branch:    feature/crypto

commit 52b534c9d13efde15841402dc86c99685334250f
Author: hgangwx <email address hidden>
Date:   Fri Dec 11 17:31:36 2015 +0800

    Fix some inconsistency in docstrings
    
    Added colon after ":returns" according to:
    http://docs.openstack.org/developer/hacking
    
     blank lines are added before the param lines
    
    Change-Id: I008bea270c6a4b7c80d1a84a2cb9fcc9b5a7264a

commit 19c7dbc0ba49ff7e1f59190a7ead9ae9d3d80238
Author: Mahati Chamarthy <email address hidden>
Date:   Fri Dec 11 12:27:18 2015 +0530

    Update versioned_writes doc
    
    Change-Id: Ibe53c79cf49330332112001c02a2a6b078764130

commit 70bc3d1a3a240c35eba934010fdef99a775b8715
Author: John Dickinson <email address hidden>
Date:   Tue Dec 8 16:08:04 2015 -0800

    added a few ruby clients to associated projects
    
    Change-Id: I4764ba505646949ff694f8939947f83c6940128a

commit 7035639dfd239b52d4ed46aae50f78d16ec8cbfe
Author: Clay Gerrard <email address hidden>
Date:   Thu Oct 15 16:20:58 2015 -0700

    Put part-replicas where they go
    
    It's harder than it sounds.  There was really three challenges.
    
    Challenge #1 Initial Assignment
    ===============================
    
    Before starting to assign parts on this new shiny ring you've
    constructed, maybe we'll pause for a moment up front and consider the
    lay of the land.  This process is called the replica_plan.
    
    The replica_plan approach is separating part assignment failures into
    two modes:
    
     1) we considered the cluster topology and it's weights and came up with
        the wrong plan
    
     2) we failed to execute on the plan
    
    I failed at both parts plenty of times before I got it this close.  I'm
    sure a counter example still exists, but when we find it the new helper
    methods will let us reason about where things went wrong.
    
    Challenge #2 Fixing Placement
    =============================
    
    With a sound plan in hand, it's much easier to fail to execute on it the
    less material you have to execute with - so we gather up as many parts
    as we can - as long as we think we can find them a better home.
    
    Picking the right parts for gather is a black art - when you notice a
    balance is slow it's because it's spending so much time iterating over
    replica2part2dev trying to decide just the right parts to gather.
    
    The replica plan can help at least in the gross dispersion collection to
    gather up the worst offenders first before considering balance.  I think
    trying to avoid picking up parts that are stuck to the tier before
    falling into a forced grab on anything over parts_wanted helps with
    stability generally - but depending on where the parts_wanted are in
    relation to the full devices it's pretty easy pick up something that'll
    end up really close to where it started.
    
    I tried to break the gather methods into smaller pieces so it looked
    like I knew what I was doing.
    
    Going with a MAXIMUM gather iteration instead of balance (which doesn't
    reflect the replica_plan) doesn't seem to be costing me anything - most
    of the time the exit condition is either solved or all the parts overly
    aggressively locked up on min_part_hours.  So far, it mostly seemds if
    the thing is going to balance this round it'll get it in the first
    couple of shakes.
    
    Challenge #3 Crazy replica2part2dev tables
    ==========================================
    
    I think there's lots of ways "scars" can build up a ring which can
    result in very particular replica2part2dev tables that are physically
    difficult to dig out of.  It's repairing these scars that will take
    multiple rebalances to resolve.
    
    ... but at this point ...
    
    ... lacking a counter example ...
    
    I've been able to close up all the edge cases I was able to find.  It
    may not be quick, but progress will be made.
    
    Basically my strategy just required a better understanding of how
    previous algorithms were able to *mostly* keep things moving by brute
    forcing the whole mess with a bunch of randomness.  Then when we detect
    our "elegant" careful part selection isn't making progress - we can fall
    back to same old tricks.
    
    Validation
    ==========
    
    We validate against duplicate part replica assignment after rebalance
    and raise an ERROR if we detect more than one replica of a part assigned
    to the same device.
    
    In order to meet that requirement we have to have as many devices as
    replicas, so attempting to rebalance with too few devices w/o changing
    your replica_count is also an ERROR not a warning.
    
    Random Thoughts
    ===============
    
    As usual with rings, the test diff can be hard to reason about -
    hopefully I've added enough comments to assure future me that these
    assertions make sense.
    
    Despite being a large rewrite of a lot of important code, the existing
    code is known to have failed us.  This change fixes a critical bug that's
    trivial to reproduce in a critical component of the system.
    
    There's probably a bunch of error messages and exit status stuff that's
    not as helpful as it could be considering the new behaviors.
    
    Change-Id: I1bbe7be38806fc1c8b9181a722933c18a6c76e05
    Closes-Bug: #1452431

commit 62b9a0eeeaeb3a5a0daff981cf6fa1cb50e78a50
Author: Clay Gerrard <email address hidden>
Date:   Mon Dec 7 10:19:51 2015 -0800

    fix mock and assert in test_direct_client
    
    Change-Id: Ia6c14377e5dd768a5306a2448f0bf244ebc3634e

commit b63caf4521b0a4a32b9afdb6d247537848d0a8d6
Author: Tushar Gohad <email address hidden>
Date:   Wed Nov 11 12:53:29 2015 -0700

    Bump PyECLib requirement to >=1.0.7
    
    ... to match global-requirements.  This is an
    intermediate step in updating requirements to
    PyECLib>=1.1.1.
    
    Change-Id: I79f47fff6ec1adff214ca435f0d95aaf1ffd68f9

commit 73ded056aff0f25605fee2a633f3d13e0369606a
Author: Christian Schwede <email address hidden>
Date:   Tue Dec 1 14:59:35 2015 +0000

    Add functional test for repeated SLO segments
    
    Currently fails on master, passes with change
    If13af444ed301ebd8fd34a0d96a330ded648f0c4 applied.
    
    Change-Id: I05b231cc232d5b4117bccee40eebc7093114c61c

commit 28c4b7310fead32f7ce073ee4bb503a450e521f1
Author: Peter Lisák <email address hidden>
Date:   Tue Nov 24 16:33:35 2015 +0100

    Unification of manpages and conf-samples (default values, etc)
    
    Change-Id: I47a3127ef698b4bd1537b1562901ee9c2b5924d4

commit 635bc7fa8f9a442b39af4955e98fcd2e2acf1e0a
Author: Ferenc Horváth <email address hidden>
Date:   Wed Oct 7 11:10:28 2015 +0200

    Replace string slicing with proper string methods
    
    Updated string prefix and suffix checker slicing to startswith()
    and endswith() methods.
    
    Using startswith() and endswith() improves readability, error-proneness
    and enhances maintainability.
    
    Change-Id: I1d5fbf116a61763346c6f92fd8023dbbe9bb37cf

commit c28709f8f264f4426364b67a2a2755311111c1e4
Author: Samuel Merritt <email address hidden>
Date:   Wed Nov 25 17:09:34 2015 -0800

    Fix crash when a SLO repeats a segment.
    
    If a SLO manifest specified the same segment twice with no range on
    the latter, we would crash while trying to coalesce the segment
    specifications into a single request (for efficiency). Now we handle
    that missing range and do the right thing.
    
    Change-Id: If13af444ed301ebd8fd34a0d96a330ded648f0c4

commit 213b1a4900a75f6a0eac4af6ee53ca9c367bbd41
Author: Paul Dardeau <email address hidden>
Date:   Mon Oct 26 21:17:05 2015 +0000

    Added unit tests to recon.py.
    
    Added tests for unrecognized recon_types for get_replication_info,
    get_updater_info, and get_auditor_info.
    
    Added tests for get_device_info and get_swift_conf_md5.
    
    PEP8 compliance fixes.
    
    Updates based on code reviews.
    
    Change-Id: I3f636955b253ea7f65d4a1f333a0ad24f1ea6a1f