Difference between revisions of "Swift/ideas"
< Swift
Line 13: | Line 13: | ||
* change the ssync (object-replicator) design to be run as another process for concurrency | * change the ssync (object-replicator) design to be run as another process for concurrency | ||
* durability simulator based on swift specification (e.g. # of replicas, # of devices and network speed to replicate) | * durability simulator based on swift specification (e.g. # of replicas, # of devices and network speed to replicate) | ||
+ | * in the situation where a proxy needs to talk to a storage node on the same server, call the storage node method(s) directly instead of putting bytes on the network |
Revision as of 22:34, 12 September 2014
Ideas for OpenStack Swift
- use keystone api in swift client, if possible
- in multinode install docs, show mounting with a label - https://review.openstack.org/#/c/119193/
- change default ports - https://review.openstack.org/#/c/118200/
- reverse listings
- stdin streaming to swiftclient
- reload swift config files when a change is detected (like current ring behavior) -- please don't do the auto-reload, I often edit them in-place (zaitcev)
- ring validator (in swift-recon): eg test that something is running on the ports in the ring -- not just "something", must verify correct type, because deployers sometimes flip a/c/o and then inexplicable 400 happens
- deep health check to test all the way to drives (? or at least storage servers)
- better ring deployment inside of swift itself
- need internal net sec enforcement - https://blueprints.launchpad.net/swift/+spec/secure-internal-network-requests
- change the ssync (object-replicator) design to be run as another process for concurrency
- durability simulator based on swift specification (e.g. # of replicas, # of devices and network speed to replicate)
- in the situation where a proxy needs to talk to a storage node on the same server, call the storage node method(s) directly instead of putting bytes on the network