ec this week

gistfile1.txt

Getting closer. Thank you for your hard work. This is the best and
biggest (most diverse) community effort I've ever seen in Swift.


As of today (for some version of "today", depending on your timezone),
all functional tests against a cluster with a default EC storage
policy!


So what's left? The starred patches on the review dashboard are the
outstanding pieces of work: http://goo.gl/uRzLBX. There are 5 patch
chains there. In order of priority, they are:

- Multiple fragment archive support for suffix hashes
  (https://review.openstack.org/167595)
- Validate the PUT method extraction for suffix hashes
  (https://review.openstack.org/164950)
- Support multi-range GETs for EC objects (also, resumable GETs)
  (https://review.openstack.org/166576)
- Update container-sync to use internal client
  (https://review.openstack.org/167595)
- Select the policy when running functional tests
  (https://review.openstack.org/143791)

The first one listed is where the reconstructor is coming in (in that
patch chain). This part is crucial to EC, of course.

The next two have a lot of importance too. They include proxy
refactors to make it clear what is EC and what is replication. This
really will help with the merge to master, and it will make it a lot
better to maintain over time when we (invariably) start tracking down
bugs in the code. Also, there is some important functionality hanging
off of the multi-range patch for error handling and connection
cleanup.

The last two listed are important for a full production release of EC,
but not as important for the EC beta. They are very good to work on if
you've already reviewed/patched the others.

Paul is out for the remainder of the week until Monday (20th wedding
anniversary trip), but I've seen everyone picking up the patches, so
I'm not too worried about slowing down too much for the next two days.

Next week (based on the patch chains listed above), we'll begin the
merge to master. Clay is taking point on managing the patch chain. It
will look very similar to what we did last year with storage policies:
we'll review a patch chain and merge it as a single merge commit into
master once the whole thing is reviewed/approved.

The plan is to have a release candidate on April 10. This gives us
time, if needed, to have a second release candidate, but let's try not
to do that. A second release candidate should be for critical bugs,
not for extra polish. The OpenStack Kilo release date is April 30.

There are a couple of things to keep an eye on, as we get closer to
the merge. First, docs. We'll be including docs in the release (a
feature isn't done without docs). These don't need to be hugely
detailed things (eg we can't really have performance recommendations
yet), but an overview of the design, and how to use it is important.
Secondly, tests. We have ok test coverage now, and there's some more
tests in the patch chains. We're normally pretty good about keeping
test coverage high. Please let's not skip tests at the end for the
sake of shipping (untested) code.

Thanks for all your hard work.