Updated openstack/openstack
Project: openstack/glance  368dc7cdd703a6a86fcf3386c52ceb577df6ccd7
null
Move scrubber outside the store package

Glance's scrubber was created under the store package because it is
intended to clean up images from stores when `delayed_delete` is
enabled. However, it doesn't really belong there.

Soft delete is a Glance feature that allows images to be deleted
asynchronously as opposed of blocking clients requests during the image
deletion. Therefore, it needs to be store agnostic and live within
Glance's codebase.

Partially-Implements blueprint: create-store-package

Change-Id: I25ddbe1f0f1191f33d814dbae5788da7d511773a
Updated openstack/openstack
Project: openstack/oslo.messaging  bf3896d462a5e1ffff2853540157d6c1aca0b1a1
null
Remove unused eventlet/greenlet from qpid/rabbit

Because driver should rely on executor and not directly on eventlet,
delete eventlet/greenlet related code.

qpid/rabbit part.

Change-Id: I20a0850d54b6c6f81957beabb12f7d67f0c1e741
Updated openstack/openstack
Project: openstack/swift  57603b7c58f1c9498f2918c7001d905310d634a4
null
Sanify handoff search depth with non-integer replica counts

On GET, the proxy will go search the primary nodes plus some number of
handoffs for the account/container/object before giving up and
returning a 404. That number is, by default, twice the ring's replica
count. This was fine if your ring had an integral number of replicas,
but could lead to some slightly-odd behavior if you have fractional
replicas.

For example, imagine that you have 3.49 replicas in your object ring;
perhaps you're migrating a cluster from 3 replicas to 4, and you're
being smart and doing it a bit at a time.

On an object GET that all the primary nodes 404ed, the proxy would
then compute 2 * 3.49 = 6.98, round it up to 7, and go look at 7
handoff nodes. This is sort of weird; the intent was to look at 6
handoffs for objects with 3 replicas, and 8 handoffs for objects with
4, but the effect is 7 for everybody.

You also get little latency cliffs as you scale up replica counts. If,
instead of 3.49, you had 3.51 replicas, then the proxy would look at 8
handoff nodes in every case [ceil(2 * 3.51) = 8], so there'd be a
small-but-noticeable jump in the time it takes to produce a 404.

The fix is to compute the number of handoffs based on the number of
primary nodes for the partition, not the ring's replica count. This
gets rid of the little latency cliffs and makes the behavior more like
what you get with integral replica counts.

If your ring has an integral number of replicas, there's no behavior
change here.

Change-Id: I50538941e571135299fd6b86ecd9dc780cf649f5
Updated openstack/openstack
Project: openstack/cinder  e61a9303274d4cad7411fe35a597a30eb5518633
null
LVM: log thin pool name and size upon creation

The thin pool creation size may not be obvious to the user, so a log
message may help alleviate some confusion.

Change-Id: I3a98b610be612a4fb7496a89f9005012c9210bf8