 Hello, thank you for having me. These things are always fun for me to do. I love the summit time frames when we're talking about summaries of what's going on because it gets a chance to see exactly what's, reflect on what's happened and how we can go forward from here. So my name is John Dickinson. I am not my name on IRC and Twitter, and I am the project technical lead for OpenStack Swift, which is the object storage component of OpenStack. The background image that I chose here is one of the international prototypes for the Kilogram, and the principal one is stored near Paris, and since the summit was there, that's what we named the next integrated release in OpenStack. We called it the Kilogram release after that international standard that is stored near Paris. So I think that was kind of a cool choice, and I really liked that. I think it actually reflects a little bit of what's going on inside of the community overall and something that I have seen inside of Swift as well, and I'll come back to that in a little bit. But as a high level summary, Swift is an object storage engine. It is built for scales, optimized for durability, availability, and concurrency across the entire dataset. My vision for Swift is that everyone will use it every day, even if they don't realize it. We see this in a lot of places. Swift is perfect for unstructured data that can grow without bounds, things like content generated and consumed by web and mobile apps, backups, documents, videos, pictures, that kind of stuff. I want to see people using Swift when they're helping their kids with their homework by looking stuff up online. I want to see people using Swift when they're filing expense reports, when they're checking their bank balance, when they're watching videos online, all of that kind of stuff are places that are great for Swift and in fact where Swift is being used today. So my overview is a summary of what's going on in the community. It's not dates or schedules. It's more of a reflection of conversations that are happening. And so that's kind of what I want to share with you. So looking at who's going on in the community, first just kind of an update of the community side of things before we get into the technical piece. Who's participating in the community? I think it's always an interesting question. And so we still have the most prolific and active daily contributors into Swift these days are familiar names in the community, Swiftstack, Red Hat, HP, Rackspace, Intel, all of whom are contributing into keeping Swift healthy and pushing it into new directions. And it's a really solid base of contributors and I'm proud to work with them. All of them are really solid, strong contributors technically and strategically. And it's just a pleasure to work with these companies and to see both what they're doing in the marketplace but also how they're bringing their varied expertise and experience of different use cases into the development community itself. And so that's been really exciting for me to see continue in this recently and then going forward in the community. So what's next? What are we seeing? Next slide please. I think something that's really kind of cool is that we're seeing a lot more uptick and things that I'm hearing are a lot more of Swift being used and supported by third-party ecosystem apps. I work for Swiftstack and I have interactions with people in the ecosystem quite a bit. And the thing that I am hearing unprompted from people is that there's basically two object storage APIs that matter today, S3 and Swift. And that is something that's really tremendously exciting. And I was talking about the Kilogram is a standard that people adhere to. And I think what we're seeing also is the OpenStack APIs as a standard beyond what we like to tell ourselves internally in the community but actually hearing feedback from people who are not involved in the day-to-day minutiae of OpenStack itself but actually just looking at this from a very broad ecosystem perspective. We're seeing OpenStack APIs become supported as first-class citizens. And so one of the things, a few things that I guess that are very interesting I've seen recently is looking at major applications like Commvault and Veeam that are used in very large enterprises today. Supporting Swift as a first-class citizen, Storage Made Easy is one that has been adding a lot of great support recently. Gladonet, in fact, just this morning announced a tighter partnership with Helion Swift. And that's in addition to kind of some of the old favorites that have been in the ecosystem for a while like CyberDoc and ExpandDrive. And of course there's a ton of people using Swift internally for internal apps, they're writing their apps to talk directly to Swift. And so this is really kind of cool because what we're seeing is that Swift is becoming the thing that people are talking to for object storage. And this is because, I guess because and as a result of this both, we're seeing more and larger clusters of Swift in the overall installed base. This drives demand for some of those more traditional enterprise features. And it of course means that people need things like more automation. And I'll touch on some of these kind of things that we're talking about in a little bit. And so in addition to that, in addition to these third-party client apps, but I think part of the same story is that we're also seeing in the community more integration and interest from other storage providers, both with a native integration using Swift's extensibility points to integrate natively, but also their own support of the Swift API. And so all of that is very interesting looking at both who's contributing to the community, but then also the very large ecosystem about people who are building applications and products and businesses around Swift itself and based on Swift as a standard object storage API and implementation that can store the data that people are using for applications today. And so that actually leads me to an interesting new development that we've got in the community right now. So we have been talking about how to make things better for applications that are using Swift. And a lot of times the very first interaction that people have with Swift is using the official command line interface, the CLI, or the official Python development toolkit called SDK. And so these things are part of the code base that we maintain as a Swift project inside of OpenStack. And so we've decided to make some changes in some of our direction of what we're going forward here. They're kind of a long-term effort. First off, the CLI is something that we are going to continue to keep and maintain and add features to and fix bugs in and add additional polish to and all of that. It's something that is a very useful tool for a lot of people to be able to interact very easily from a command line with a Swift storage endpoint. The CLI uses the SDK. That is the Python wrapper to the OpenStack Swift API. The API itself is simply using HTTP. So standard HTTP verbs and response codes. But we've got a higher level wrapper around that written in Python that allows people to interact with it programmatically a little more easily. And the command line interface makes use of those tools. Now, there has been an effort inside of the OpenStack community to create a single OpenStack SDK project to give all of the OpenStack projects a more unified SDK and then a single library that people can consume can then talk to all of the OpenStack projects. It's very early, especially for their implementation and their support of Swift right now. But it's rather a fortuitous time for us to very closely work together so that the Swift community and the OpenStack SDK team. And so what we're looking at and what we're talking about right now is taking any efforts for future features and new directions and rewrites and things like that of the Python Swift client SDK. And instead of focusing it there, we will focus on the new work that's being done inside of OpenStack SDK. What this allows us to do is make things a little more efficient and take the knowledge that we've developed over the last four or five years of writing Python with client SDK and taking those lessons and doing it right and doing at least better this time so that we can focus on things a little bit more like efficiency and performance and stuff like that. So since these guys are essentially starting from scratch and we realized that to do all of these major changes we essentially have to start from scratch, we figured out that it would be a really good opportunity to work closely together to share the workload but also make something that's pretty cool. So this is a long-term ongoing effort. It is something that is, again, it's not a particular schedule or timeline or something like that, but it's more of a general conversation we're having inside of the community. We, of course, are going to be very focused on maintaining compatibility and making sure that existing applications do not break and we're not abandoning Python Swift client right now at all. So we will continue to improve that. We'll continue to make sure that bugs are fixed, especially on the CLI side but on the SDK side we're going to look at putting some more effort behind the OpenStack SDK project. So that's a change there that we're working on and that's going to affect some things going forward as far as how clients interact with that. So what else is next? There's another open source heavy group called the GNOME Foundation and they have an outreach program which is kind of an internship program and it's something that is designed to get underrepresented groups involved in open source. So it's a really great goal and something that I'm really happy to say that OpenStack has been a part of in the past and has continued to invest time and effort into. For the current round of the GNOME outreach program OpenStack has six interns participating across the various OpenStack projects and one of those interns is working on Swift and is focusing on improving some operational tools and it's something that is really just a – I'm really happy that it's happening and our intern inside of Swift is jumped in and has already made some contributions into Swift and will continue to add in some tools specifically designed to do some operational checking to validate OpenStack deployment or Swift deployment just to make sure that everything is working well. So that being said, as far as where the community is and who's working on what and kind of the ecosystem around it and the little changes we're making on the Swift client, I want to go a little bit into a new process that we have called SPEX and what that is meaning for – how that's been framing the conversations that we've been working on. So SPEX are basically a collaborative design process for bigger features within Swift. There are several parts of the – several different projects inside of OpenStack that have adopted some sort of SPEX process and it's something that is kind of caught on like wildfire but I think it's very early in figuring out how does this process actually work? And so it's good to think that this is an experiment. The goal here is to increase communication. The goal is not to have another process to do something. So this is kind of our second try at making a SPEX process for Swift that is effective and works. And so our kind of thing that we're talking about that we're using inside of this integrated release cycle is to – when a spec is proposed, we want to iterate and land on the – land on those specs very quickly. We're not going to look for this big design document up front that has every possible contingency and use case and corner case defined and explored out. What we want to do is we want to have it as a way to improve communication, especially when people are working across different companies, across different time zones and things like that. So we want to be able to – we want to land things fast as soon as we can agree on something. And we want to keep those updated as we iterate on our conversations and figure out what the best way going forward is. And as the coding happens, so once we agree on – this is a thing that we think we should do. Then when coding starts, we want to keep the spec updated based on our – keep the spec updated based on what the implementation actually does. So another point of this is that specs are not docs. Docs are different, so they have a different audience. Specs are designed for the communication. So that being said, what are some of the things that we're talking about? Next slide. What are actually – what's actually going on inside of the community? What's being worked on? What are these conversations, these collaborative conversations that we're actually having? Well, one of the first ones is a big one that we've been talking about quite a bit. Erasure codes. We have a major feature that landed several months ago inside of Swift called Storage Policy. Storage Policy is allowing you to configure how that is stored inside of your cluster at a very fine granular level. One of the things that we can build on top of that is to be able to actually configure how your data is stored across a set of hardware. So today we use replication, and then we're building the feature to the Erasure Codes on top of inside of your Swift cluster alongside of replication. So the data that needs to be stored that way can be. So what's the status? This is a little screenshot of the status – our Trello board status as of last night. Basically the progress is good. We are working very hard and lots of people at lots of different companies are constantly talking about this. We are getting something that's going to be demobile very, very soon, and a lot of the work that's been done up to this point has been spent on some very hard design problems and making sure that we have these kind of fundamental problems figured out before we start doing some of the more demobile things like, oh, well let's just read and write the data up front. So one of the hard problems that we're figuring out that we're planning on being able to support as of this point is the ability to overwrite objects that have been stored as Erasure Coded data. This doesn't sound like a very hard problem, but when you think about the fact that the different components that make up the Erasure Coded object are in fact stored across a lot of different pieces of different physical hardware, the coordination problem becomes rather tricky when figuring out well, what is the actual instance or version of the object that you are actually trying to keep and maintain and know that that's going to be your durable copy. So that's a hard problem that we're trying to figure out. And it's complicated by the fact that SWIFT does not have the concept of a global lock. So you can't lock the cluster down or even lock a particular object down and say, okay, well now we're going to have something that's going to be basically an atomic operation or even just an operation inside of a transaction that you can roll back. That doesn't actually work inside of SWIFT as a distributed system. So we've got to figure out how do we make progress on this and allow the Erasure Coded objects to have the same semantics as replicated objects from a client perspective. So we're working really hard on this and these are some very tricky problems that we're trying to solve and it's going to be done when it's done. This is our top priority inside of our current integrated release cycle and I'm pretty confident that we're going to have something that's pretty cool pretty soon. Next slide. One of the other big things that we have seen inside of the community, some of the other conversations, especially coming from some of those big customers, they're going to be talking about some more of these enterprise features, is the concept of encryption. And encryption is, especially when you're talking about storage, it's a very loaded word that as soon as you say it, a lot of people assume they know exactly what you're talking about. The problem is there's a lot of different use cases that can be wrapped up in this concept of encryption. So what we're talking about right now on what we're hearing from users and what we're working at, the thing that people need to solve first is solving the problem of basically, if a hard drive walks out of my cluster, either maliciously or inadvertently, I need to make sure that nobody can read the data that is stored on it. So there's a lot of different ways to do this and right now we've got some very interested users and customers for this, some active conversations including a very active spec document being worked on right now as far as here's how we can have a framework by which we can implement encryption which means encryption at rest, the data at rest for data stored inside of Swift. And something that will work for different use cases that will not be too complicated but also not be too limiting for people who need to do this. So it's something that is, again, an active conversation inside a community. Next up. Next up is this thing called composite tokens. It's a new functionality to work with off systems. Basically the idea in here is that we have some data inside of Swift that may be put there by a service. So in this sense, especially looking at a broader OpenStack deployment, you could imagine that somebody has using OpenStack compute and then using OpenStack image service to store these images inside of Swift. So you don't necessarily though want to have the end user be able to delete those images without going through some other process because that could make some things inconsistent with the whole index and everything like that. So you still need to be able to track it and you need to have appropriate permissions on it. But then on the other hand, you don't necessarily want the system itself to make decisions on the behalf of the user. So the proposal here is to require for certain levels of permission that the operation requires two off tokens. One from the service and one from the user. So this is called composite tokens and it's something that has been worked on inside of Keystone. And there's very active discussions happening inside of Swift, although there's not any code in Swift for that right now. So next up. Next up is something that we call fastPost. Post is an HTTP verb and instead of Swift, it's used to modify metadata for objects. And in almost all cases right now, it is inside of Swift, it's implemented as a copy. So you send a little bit of metadata and the system will read the old data and then write out the new data with your new piece of metadata. So that works pretty well, especially since in most use cases, posts aren't done very frequently. Unfortunately, it makes it a rather expensive operation. So fastPost is something that is an improvement on that so that we do not have to do that server-side copy. This is something that there's a lot of historical reasons for why we're doing what we're doing, but suffice to say it's something that there are some active patches and reviews going in right now to see if we can get rid of that server-side copy so that we can make post operations very, very fast. And that's something that's again, along the lines of continued efficiency improvements that we always like to look at for Swift, which brings me actually to kind of the general catch-all next topic here, which is we're working on efficiency improvements inside of Swift. This is something we always want to keep our eye on especially as people are storing more and more data and having more and more users on this. Remember, Swift is designed for massive scale, massive concurrency across the entire dataset. So we have to make sure that we're the things that we're doing we're not doing too much and we're not doing them too slowly. So there's a few things that kind of go under this right now in addition to the fast post feature. Some of the stuff that we're talking about, some people are playing with and again conversations that are happening right now involve making very, very large containers more efficient. There's some improvements that I'm pretty excited about that are along the lines of improving efficiency in global replication. So if you have regions that are separated by a continent or separated by an ocean, making that a little bit more efficient. And then overall, we're of course just continuing to fix bugs, make it easier for end users and operators. This even comes back to the current project that our GNOME outreach program in turn is working on making sure that we've got some operator tools that really allow you just to validate your cluster very simply. So it's something we always want to keep our mind on and again there's lots of conversations with that. So would you like to get involved? That is if you would like to get involved, you're more than welcome. We would love to have you help out and come on in. You can get involved. The best way is hang out in the OpenStack-Swift IRC channel on the FreeNote IRC Network. There's a lot of people there in a lot of different time zones. So generally any time of the day or night you should be able to find answers to your questions and figure out how to get involved. We even have a wiki page that has just some lightweight ideas of, hey, here's something that we don't even really have any detail around it, but somebody's mentioned it more than once and it would just be kind of a cool thing to work on. So this is even a kind of a good place. If you'd like to play around with some things and you don't have your own idea of what to work on already, this is a good place to start with. And then if you'd like to begin coding and get involved with actually making the code itself better, fixing bugs and features, things like that, the best way to get involved with a dev environment is using the link provided here to swift all in one environment that can be very simply provisioned with virtual box and vagrants. So we would love to have you come along. We have weekly meetings, those you can find in IRC. Also you feel free to contact me Twitter, email, IRC and I try to respond to as much of that as I can. And that's what we have. So if you have any questions please let me know and Allison thank you for having me today.