<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">The PTG was great. Not only was there three full days of Swift-specific dev work, we had lots of opportunity to work with other projects. Here's a quick rundown of the highs and lows of the week.</p>
<p dir="auto">The first obvious benefit to the PTG is the relatively easy access to other projects. Yes, there's some issues we all need to work through related to scheduling and awareness, but the fact that we're all in the same building is useful. The Swift team was able to work with many different groups last week. I'm excited about the ongoing work around requirements, packaging/testing infrastructure, barbican, improving docs, and improving the QA process.</p>
<p dir="auto">The PTG also had the general "flavor" of previous Swift midcycle hackathons, in that there weren't a lot of external constraints on our time. It was a week devoted to working closely together, face-to-face. I'm happy that the PTG was able to preserve this aspect of midcycles.</p>
<p dir="auto">However, one downside I saw was the smaller attendance. The PTG was slightly smaller than a midcycle and much smaller than previous summits. I missed the extra diversity of opinion and especially the much smaller set of ops feedback that we had. As devs, it's very easy to get carrier away designing something that isn't actually super important to our users. Our users are the ops and admins who run the clusters, so their feedback is crucial for prioritization and knowing what particular issues are most broken.</p>
<p dir="auto">I'm not sure yet what the upcoming summit/forum event will look like. I think there's still a lot of confusion around what that will look like and who should be there. But after that event, we'll all be able to look back and see what needs to be changed (if anything).</p>
<p dir="auto">Within the Swift community, we made good progress on quite a few topics, but I want to highlight just a few. We had a lot of discussion around general storage server performance and efficiency. This topic has a <em>lot</em> of different parts, including some golang rewrites. All of these were addressed, and we'll be working through them with the whole OpenStack community.</p>
<p dir="auto">We also talked about enhancing a few existing features. One improvement we've made recent progress on is support for global erasure coding. This takes advantage of the efficiencies erasure coding brings, but it works around the challenges of deploying it in globally distributed clusters. We've landed the first part of this work (replicating EC fragments), but there's still a lot to do related to how and when the fragments in different regions are accessed.</p>
<p dir="auto">I was excited about the cross-project conversations we had with the Barbican team. We're working on enhancing Swift's encryption-at-rest capabilities, and users are asking for integration with key management systems. Barbican provides this, so we spent quite a while figuring out what's needed and what the eventual solution will look like. In addition to the Swift code that needs to be written, one of the next steps is to work with the Barbican team on gate testing together.</p>
<p dir="auto">We talked about many other things during the week. Overall, it was a great week, and I'm excited to be working with my fellow Swift contributors.</p>
<p dir="auto">--John</p>
</div>
</div>
</body>
</html>