Open Stack

Recently I polled many active members of the Swift dev community. I
asked 4 questions:

  1. What are you working on in Swift or the Swift ecosystem?
  2. Of the things you know about that people are working on, what's
     the most important?
  3. What are you excited about in Swift?
  4. What are you worried about in Swift?

Swift has a fantastic community. Right now, we’re at a global max of
active contributors[1]. Our contributor community is growing, and
we’ve got a large number of people who are consistently active. Our
upcoming hackathon in Bristol looks to be one of the largest we’ve
had, by number of registered attendees.

Not only is the size of our contributor community growing, but we see
more and more Swift clusters being deployed. One survey response that
came up several times is being excited about seeing 10+PB clusters in
production. Swift is growing in the number of deployments, the size of
those deployments, and the level of contributor participation. It’s
all very very exciting to see and be a part of.

No question, there is a lot to do in Swift and a lot going on.
Interestingly, regardless of what an individual was working on at the
moment, there were several things that came to the surface as commonly
mentioned "important things". These most-mentioned topics are:

  * container sharding
  * fast-POST
  * encryption.

All three of these topics are long, ongoing things. Interestingly, all
add end-user benefit without actually requiring any changes from the
end user. These aren’t features that are adding new (externally
visible) functionality; they are making the current system more
capable for the way users already want to use Swift today.

There is a *lot* of concern in the community about supporting the
interaction of different features. For example, understanding what
happens when you overwrite a versioned *LO via a COPY using an
encrypted EC policy (and with the different config options possible
for each of those) is hard to reason about. This makes it hard to
support, hard to test, hard to document, hard to review new code, and
hard for users to understand. Of course this is somewhat balanced by
the praise Swift gets for being flexible and adding features that
enable complex enterprise deployments. Unfortunately, the cost of
these complex interactions make it difficult to support the codebase,
add new things, and review patches.

Speaking of patch reviews...

There's also quite a bit of community concern about slow reviews. Some
of this is related to the concern around complex feature interaction.
Some of this is the ratio of cores to stuff-going-on. This issue is
exacerbated in swiftclient, where there is an obvious gap in the
contributor community.

On the positive side, there's a huge amount of praise for the
community itself. People find the community welcoming and pleasant to
work with. Even those who work in more remote time zones find it
enjoyable (paraphrased: "Before I worked on Swift, I didn't expect we
would work well together because the community is so spread out across
the world. But it's absolutely awesome."). There's one comment from a
relative new contributor about it being hard to get involved (learning
the code and community via IRC). Having an easy onramp to community
participation is very important for the health of the project.

So what are the plans moving forward? I’ve got some ideas, but
improving Swift is something we all can work together on. If you’ve got
an idea, let’s try it out!

Here’s some thoughts I have about how to improve

Goals we need to keep in mind:

  * Reduce complexity by reducing modes of operation (eg fast-POST only)
  * Remove extraneous features, modes of operation, and deprecated things
  * Add "magic" in the right places to make complex things simple and hard
    things easy
  * Respond to patch submitters quickly
  * Remember that new community members are always joining, and we must
    provide them with an easy way to get involved technically and socially.

Specific action item ideas:

  * Re-introduce the automatic config pipeline generator.
    This reduces errors around one of the most confusing parts of Swift.
    Our feature interaction matrix is exacerbated by the amount of
    middleware that is used/recommended by default. This makes it hard
    to add new middleware, and if we the active contributors are confused
    by it, then deployers have no hope. An automatic pipeline generator
    removes confusion and puts the magic in just one place.
  * Describe and test complex feature interaction (especially things
    that aren't an atomic operation). Document the feature matrix.
  * Update "getting started" docs and install guides on a recurring
    schedule. Challenge active contributors to rebuild their SAIOs from
    scratch (without an automation script) once a month.



[1] http://d.not.mn/active_contribs.png


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160212/65074716/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160212/65074716/attachment.pgp>