tl;dr: Icehouse won't have storage policies; merging the work into master will be in "logical chunks" after Swift's contribution to the Icehouse release.
Here's a quick update on what's been going on in the Swift community with storage policies. Many Swift contributors have been working on storage policies for quite some time now. It's a huge feature and improvement to Swift that enables a ton of new use cases. There's been very strong interest in this feature from both existing and new users. As a quick review, storage policies allow objects to be stored across a particular subset of hardware (e.g. SLA or geography) and with a particular storage algorithm (e.g. different replication parameters and [soon] erasure codes). Storage policies allow deployers to specifically tailor their storage cluster to match their particular use case. (You can read more at https://swiftstack.com/blog/2014/01/27/openstack-swift-storage-policies/.) When we first started actively working on this set of work, we had a goal of including it in the Icehouse release. However, that was an estimate, based on some early assumptions on what needed to be done. Work has continued very well, and we've learned both what to do and what not to do. As we get down to the final pieces of functionality and close to the Icehouse release date, it's become obvious that we will not be able to finish the work and provide adequate docs and testing in the Icehouse timeframe. This is not due to a lack of effort or fault of anyone involved; it's simply a large chunk of work that takes a long time to get right. It's a hard decision, but one we feel is the right one to make. So what could we do? 1) Just finish up the final bits and force it in right before Icehouse. Not only would we look like jerks to the whole community, if some major bug were to be revealed, we'd look incompetent. This isn't a good solution. 2) Wait until just after the Icehouse release and shove it into master. Then we look like jerks, but we have a few months before the next OpenStack integrated release to let things settle. This really isn't a good solution either. 3) Refactor the existing feature/ec branch into logical chunks of functionality and proposed those to master. This allows for better reviews, since its more digestible than a 5500+ line merge patch, and it also gives non-reviewers a clearer understanding of what's changing. Number three is what we're doing. The patches to enable storage policies in Swift are now being prepared for review and will be submitted to gerrit shortly. Looking at the Icehouse release, I'll cut a Swift release in the OpenStack RC window (March 27-April 10). This will not include storage policies. I expect that it will take several weeks to review and merge the storage policy code, and that will allow us to include storage policies in a Swift release soon after our Icehouse contribution. If you have any questions, please let me know. --John
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
