*Storage Polices
John introduced the recent changes in Swift side, DsikFile and DBBroker and Storage Polices feature. With this feature, cloud service provider could provide more flex service, like auto tiering. Paul give a demo to show how a cluster servicing with 2 & 3 replicas at the same time. People showed great interests in this feature. I think this should be the most important feature in Icehouse.
* Swift profiling middleware and tools
Zhang Hua from IBM Beijing demonstrated one profiling tool for Swift. Actually it's a middleware that collects all of the function calls to some temp file and then do post-process to get the CPU/memory/IO time/latency. It should be quite useful for developers/system administrators to get the bottleneck of the current setup. I checked about the overhead and it seems like should be OK if you're investigating on large I/O pattern. In addition, this tools can do the latency breakdown work, which is exactly we want!
*Swift drive workloads and Kinetic opens storage
Seagate shared their new tech on disks: a normal SATA disk with an small controller add-on (something like a NAS product). And they're trying to eliminate the file system layer by using NoSQL tech through network to get/put the data. There're lots of concerns on the missing functionality on NoSQL side compared to Filesystem. I checked about the Swift integration on this and it seems Swift will only use this for object-server - the account/container server will remain the same. I think this could be some good direction however the it will took a long time to use.
*Plugging in Backend Swift Services
Clay showed some key code on how to use the DiskFile/DBBroker class on Swift-kinetic case. it seems that this is quite easy but I guess the code is not working actually. Later I met Catlin from Nexenta, who is the author of 1st version LFS for Swift. Her opinion is the Swift is not so efficient even if you have a powerful backend. She said they have given up on this. I thought this is a great feature, that allows other storage venders to plug in their produces in to Swift. Also some of the performance issue might be got fixed, like LOSF issue.
*Swift operation experiences with hot contents
One engineer form KT shared a lot experience on how they cache 'hot contents' on several level: CDN, Proxy-server, Obj-server. They're proposing some middleware inside Obj-server to cache objects dynamically. And they are improving SOS to better/easier work with CDN. The key issue is how to identify hot contents? they don't find a good way to do this and is asking for help. Actually this is the key question we met in POC version EC side.
link: https://etherpad.OpenStack.org/p/Swift-kt
*Supporting a global online messing service
one engineer from Line starts with some of the key requirements on Swift. Most of the requirements are not inside the scope of Swift. I guess there needs some external S/W to handle this. e.g. they want to support 1 billion users, the authentication part became the bottleneck before request went to Swift. They're using custom application with Redis currently. In general this is a good session and lots of requirements are raised.
link: https://etherpad.OpenStack.org/p/Swift-for-messenger
* Making Swift more robust to handling failure.
Chuck from RAX shared some thoughts on Swift error handling. He's proposing that we should improve the reliability and minimize the consistency window. overall this is a great work on consistency service. I also raised our work on Flashcache to him and he mentioned some similar work is on going inside RAX.
link: https://etherpad.OpenStack.org/p/icehouse_Swift_robust
* Metadata search
Engineers from HP did a great work. They patched Swift to store Account/container/obj-metadata in NoSQL database. And they encourage community work on this. It seems that this needs some middle-ware work.
link: https://etherpad.OpenStack.org/p/icehouse-Swift-metadata-search
