[openstack-dev] [swift] Tokyo summit recap

John Dickinson me at not.mn
Fri Nov 6 17:57:12 UTC 2015


Below are some high-level notes from the topics discussed at the summit by the Swift community.


encryption
     We're continuing the data-at-rest encryption work. For our first deliverable, we'll have a feature that allows operators to set an encryption key for the cluster and all encryption will be transparent to the end-user. There's still a lot of work to be done, but we've made very good progress, and we think we know the missing parts.

container sync
     IBM in particular is interested in improving container sync. Specifically, there are two ways to improve it. First, improve throughput by increasing concurrency and parallelism. Second, reduce cluster load by improving the ways in which we find objects and containers that need to be synced.

hummingbird
     Rackspace has some impressive results from their hummingbird experiment. It still doesn't have feature parity, but Rackspace has some internal tests to suss out where the gaps are. They should be releasing those soon. Additionally, there are some good lessons to learn from the way hummingbird is doing replication that can be applied to the Python implementation. There is still some anticipated work on hummingbird to further improve replication, and that may invalidate any Golang/Python integration work now.

ops feedback
     Operators asked for better support around finding what accounts are in the cluster. This is used for utilization. Everyone needs it, and everyone implements it slightly differently. Operators would like support upstream for an approved way to find accounts.
     Additional ops requests included more info around per-disk usage metrics and better account/container replication.

swiftclient
     Much of the pain in using swiftclient is around auth. It's hard to find what the right parameters are and how they are used. We're investigating better keystone integration, and we will be raising the default auth version used from v1 to v3.
     Much of the rest of the pain around using swiftclient is from a lack of docs. We'll be building a docs outline that will be used as a TODO list where will will add additional docs, including examples. These docs are intended to be used by end-users (CLI and SDK consumers).

ring placement
     Clay is improving the way partitions are placed in the ring during a rebalance. This matters a *lot* for smaller clusters and clusters that are adding significant capacity (eg whole new failure domains).

EC patches
     We've got ongoing work in EC to improve the way it works and fix bugs. Most of this is already proposed to gerrit.
     We've also spent time characterizing EC performance in various clusters with different configs. We'll be using this data to further improve EC support in Swift.

symlinks
     There's a lot of interest in a symlink functionality in Swift. Any sort of data migration or changing policies would likely make use of this. Although there is a very basic amount of functionality implemented as a PoC today, there's a lot more to be done before this is "done". Mostly it's been a design exercise so far.

container sharding
     Matt is working on container sharding and shared some impressive results from his current dev work.

fast-post
     Alistair has been working on getting fast-POST to work properly. It's nearly done and pretty much needs some reviews for the patch (albeit with a few outstanding comments addressed).

Data migration and policy management
     There's ongoing discussion about migrating data between policies, changing policies, and using different media for auto-manged storage tiers. Much of this work is happening in the 3rd party ecosystem and/or is dependent on other not-yet-completed work (like symlinks, notifications, etc)

python3 plan
     We've got a plan to slowly get py3 support in Swift. This matters because distros will start shipping py3 as a default (or py3 only) next year. The current plan will end up being a long slog, though.

defcore
     For further integration with DefCore, we must get the testr support for our functional tests merged soon so they can be run via tempest. Then we can start categorizing the newly-available-to-defcore tests into defcore capabilities. Anything that goes into existing capabilities become a test that clusters must pass. Any new capability goes through the defcore process to become a required capability in 2017.

Keystone policy support
     We are moving towards adding oslo.policy support in swift keystoneauth middleware. First step is to ensure we have comprehensive functional test coverage of the auth mechanisms before modifying the middleware



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151106/78a04b0f/attachment.pgp>


More information about the OpenStack-dev mailing list