At the HK summit, the topic of hot content came up and seemed to broken into two parts. 1) developing a "caching" storage tier for hot content that would allow proxies to more quickly serve small data requests with even higher rates of concurrent access. 2) developing a mechanism to programmatically/automatically (or even explicitly) identify "hot" content that should be cached or expired from the caching storage tier. Much progress has been made during this development/release cycle on "storage policies" [1] which would seem to offer a semantic building block for the caching storage tierr - but to my knowledge no one is actively working on the details of a caching storage police (besides maybe a high-replica ring backed with ssds), or the second (harder?) part of identifying which data should be cached or for how long. I glanced at those blueprints and I'm not sure they line up entirely with the current thinking on hot content - probably be a good idea to revisit the topic at upcoming summit in ALT. I believe proposals are open. [2] -Clay 1. https://blueprints.launchpad.net/swift/+spec/storage-policies 2. http://summit.openstack.org/ On Mon, Mar 10, 2014 at 10:09 PM, Anbu <anbu at enovance.com> wrote: > Hi, > I came across this blueprint > https://blueprints.launchpad.net/swift/+spec/swift-proxy-caching and a > related etherpad https://etherpad.openstack.org/p/swift-kt about SWIFT > object caching. > I would like to contribute in this and I would also like to know if > anybody has made any progress in this area. > If anyone is aware of a discussion that has happened/happening in this, > kindly point me to it. > > Thank you, > Babu > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140311/06bc4fad/attachment.html>