 Good morning. Welcome. Thank you for coming. I've never had a session slide at any OpenStack summit that is this early in the schedule, so rushing out of the keynotes and into here it's kind of fun. So this whole session is about meeting a lot of the people who are involved with OpenStack Swift. So we've kind of set this up with a panel style discussion. I've got a few questions that I want to go over with people here, let them share their thoughts. I will allow them to introduce themselves momentarily. My name is John Dickinson. I'm the project technical lead for Swift. I've been around in Swift since it began, and it's been a really fun five years working on Swift in OpenStack. But to get things started, can you please introduce yourselves? Who are you ready to work? And then we'll get into some of the other questions. Hi, I'm Paul Luce. I'm a principal engineer at Intel. I've been working with Swift for about two years, I guess. I've been on the core team for about a year and passed on to Matthew. As Paul said, I'm Matthew. I'm Australian. I apologize. I work for RexBase in their private cloud area. I'm usually being a call, so I'm the whipping boy. My name is Clay Gerard. I work at SwiftStack. I've been a Swift core contributor for a while. Hi, my name is Kota Tsuzaki. I'm working for entity in Japan, and so I'm working for about three years, but just only me, not core team. Hey, my name is Christian Schroeder. I'm working for Red Hat as a principal software engineer. I'm based in Hamburg, Germany, working on Swift like two and a half years now, and been a core reviewer since one year from now. Hi, I'm Alistair Coles. I'm with HP in our Helion engineering team. I'm based in the UK. I guess I've been working on Swift for about two years, and for the last year I've been a core reviewer. Thank you. So the way we've kind of structured this, we've got some questions that I'm going to go through. Not everybody will answer every single question, and then we'll try to save a few minutes at the end so that if you have questions for any of us, feel free to ask them, see what's going on, whatever happens to be on your mind. So to start with, what do you like working on in the Swift community, and how did you get involved? Okay, I'm going to start. So I got involved in Swift like two and a half years ago. At that time I was looking for a feature that was missing in Swift, so I started digging into the code, developing that feature. Did we manage to merge it? Yes, yes. Happily. And it was very helpful. The community was very helpful. Getting this merged was really great, and happily I was able to continue my work on Swift afterwards. So what I really like in the community is the diversity. So we have a lot of companies in the community. We have really helpful people. We have a lot of expertise, I think, and it's amazing to work with this community. I mean, if you just look at the erasure coding stuff that happened just in the last few months, it's amazing what happened. We were developing like 24 hours a day across the globe with different teams. That was great. Yeah, okay. I got started in Swift in a bit of a different way. I was at, I think, the Atlanta summit, kind of checking out open stack stuff. I happened to wander into one of the design sessions for Swift. These guys are awesome. And so I started helping out and started doing code reviews, and it was just very inclusive. It was an amazing team. What kind of stuff do you like to work on in the project? Like, are you really interested in, hey, let's figure out how we solve these API problems or let's figure out how we deal with file systems or any, like, some of the technical bits? I'll continue talking, because I'm here. I guess, for me, I started off doing a lot more code reviews because that was kind of needed. And it was really interesting to kind of really get my hands dirty in the code and say how people did things. And then I somehow put up my hand to do container sharding. And now that's what I'm trying to do. It's a big problem. So hopefully I'll solve it. For those who don't know, container sharding is figure out how to scale container listings so that you can have, like, 50 billion objects in one particular container inside of Swift. Yeah, someone's going to say one of the things I hope it wouldn't be just one container, but a set of containers that acts as a single namespace. Matt will figure it out. That's the plan. Let's not have a working session right now. I was going to add that one of the things I enjoyed about joining in and working with Swift is it's actually pretty stable and decent code base there when I joined, which is really great to work with. But at the same time, there's been plenty of opportunity to actually do some creative, innovative stuff to add to that. And I think we have a bunch more stuff coming to in the future that we're already kind of getting excited about. And that's been really great. And just to add again, you know, the community is is diverse, and it's getting more diverse. And I really enjoy that. And every every day I learned something from the other members of the community that I'm working with. So when you're when you're getting involved in your day to day work, how do you figure out what to work on? Inside of Swift? Can't work? Yeah. Well, how do you figure out what to work on? Like, it's Monday, what am I going to do today? So I'm working. Yeah, that's right. So I'm working with coffee. So I'm working on Japanese time zone. So just the first time fast. So I'm open IRC client with talking about barrier guys. And next, I'm coding and working for many stuff of Swift. And then working with European guys to talk about a lot of features in Swift, I think. What are some of the So I want to talk about how we figure out what to work on because Koda mentioned one of the really important things is that we all get in our open stack IRC channel open stack Swift. So I'd like to encourage especially for new contributors, one of the biggest things, you know, everybody was talking about community when we were talking about this and being being coming up to that community and being a part of that is a the most important thing to get involved. If you're available, if you have a patch up that's really important to you and you're available for people to ask questions and get ahold of you, then we're a really engaging group of folks. So I tend to like go and look at patches that are older, maybe that somebody hasn't looked at in a while. You know, I think we do tend to avoid patches that have a negative feedback. So if myself or Alistair comes along and says, you know, this patch is great, I appreciate what you're doing. These things need to be changed and he and there's a minus one on there. All you have to do to clear that minus one is push up a new change, you know, it can be update the commit message, fix something if you're not clear on what the core contributor is asking you to change. If you're not unsure about those review results, find them in IRC channel and demand that they explain to you potentially with the code diff exactly what it is that I need to fix in order to get this going and that iterative process is who's going to help those new contributors get it or went long enough and clay will just rewrite it for you or merge it behind me and then I'll have to go back and clean it up. So you know, one of the things other than the day to day tactical stuff as far as what we decided to work on, I think that's probably pretty clear, right? Most people have their day to day kind of goals and their open patches and things are looking at. But I think what's really cool about the community is how we look at the bigger fish items, the longer term aspects and we've got several different specs right now that are all open, a lot of really cool big projects. And it really is, I think every company has a slightly different reason for participating in the community. And John does a really good job of helping us prioritize these and making sure that each one is really a win-win for our contribution as well as for Swift and the operator. So I think it works out really well. Yeah, I agree with what you guys been saying. And for me, when it comes to reviewing, I've always got an eye on the topics that we have agreed specs for. The topics that we've discussed either in working sessions here or when we have our mid-cycle face-to-face meetings, which by the way are great. I think, I don't know, somebody, maybe it's Clay characterized them as coffee, meat, argue, repeat. But they are so productive in terms of getting the community on the same page and understanding where we're trying to go with new features that people are bringing. So as a reviewer, that's one answer to how do I decide to work on. And stuff that just annoys me that I want to see fixed. As a developer, then I'm looking at what my customers are feeding back they want to see going into Swift. If you're a new contributor and you want to find something to work on, then we've also got the Swift Wiki pages. And there's an actual page there called Swift Items or whatever it's. Ideas. Ideas, there you go. Thanks, PTL. Swift Ideas, some kind of things you can start to take a look at or take a bite out of for those who don't have anything. Usually, like Alastair said, it also comes from our customers to propagate up to us. Yeah, and if you're a new contributor, we have from time to time low hanging fruits. So these are simple fixes that we don't do on ourselves, but which are really easy to fix and should get you started to get into the community. Cool, thanks. So a lot of things have been said like, oh, well, there's these new features coming up and things like that. So what are some of the recent things in Swift that you're really excited about that have already landed inside of Swift? What isn't exciting about the new recent features, right? So I mean, they're all just awesome. And in fact, I got involved with Swift two years ago, specifically for erasure codes, right? We wanted to see that happen. And yeah, so I just couldn't be happier at how it's all come together and we've got the beta in Kilo. But before that, right with storage policies that John and I talked about on stage in Atlanta. And that was really just a just tremendous foundation for extensibility and not only for erasure codes, but for just all sorts of other things. And in fact, there were multiple talks in Paris. And I think what do we have 19 talks this time that have Swift in the title? If you go count them, it's just that the popularity is just nuts. It's great to be a part of the community and and features like storage policies and erasure code and container sharding and encryption and the list just goes on and on, but they're all awesome. Yeah, I was very happy to see the issue called RANDIT in the Kilo release. So the reason I worked on the EC course, so our company just published an announcement to Plugable Erasure Code backend for OpenStack Swift yesterday evening. So it's really good. And so yeah, I saw that. So a brand new backend that you can put into the Plugable Erasure Code backends for Swift that not only does the erasure codes, but also does like Secure Secret, like encrypting the erasure coded pieces. And that's really cool. What is it called like SS? Super high speed secrets sharing. Super high speed secret sharing. So SHSS anyway. So that was really cool. I saw that this morning. Thank you. So I'm very happy to land my patch for Global Cluster. Oh yeah, the Global Cluster improvements also great. Yeah. So in the half year, I'm really good activity for OpenStack Swift, I think. So apart from erasure codes and global replication improvements, another thing we landed for Kilo was support for something called service tokens. And I think that's worth mentioning because it's a really good example of working with some of the other projects in OpenStack. So without going to the detail, it's just a way in which the Keystone Auth middleware will accept two tokens and validate both of those tokens before authorizing a request into Swift. And that started out as a requirement or a desire from a colleague on the Glance project coming to us and saying, hey, this is something we'd like to better do to have Glance as a service generated token and combine that with the end users token. And it meant going and talking to our collaborators on the Keystone project and they very kindly put some support in for service tokens. And then we did our work on our end on our Keystone Auth middleware. And that all came together in the Kilo cycle. So I think that's a really good example of some good cross-project collaboration going on. And I know Alistair, you're working on some pretty cool stuff right now that's not yet developed. So kind of, I think the next question is, what are the things that are upcoming that we haven't finished yet, but should be coming later this year or next year in Swift? Or whenever they're ready. I couch all of those, you know, whenever we'll get them right. Yeah, there's a ton of great stuff. Alistair was talking about these times when you come to these sessions and you get to meet with people face to face and Alistair is so great about that. I can kind of berate him. I think, ah, this isn't going to work if we do it like this. And then, you know, we split up and he goes back to England. I go back to San Francisco and then he pings me on IRC. So I've been thinking about that. And actually you're wrong. So we can do it like this. And one of the things that he's working on that I'm really excited about is improving the way that we store metadata. It's kind of a first stepping stone towards well, just improving some performance characteristics and also sort of unifying the way that we handle metadata at the container and object levels. And that's really exciting. Lots of other exciting stuff. You'll note that I travel across the Atlantic before I tell Clay that he's wrong. So I was going to say, another cool feature that's coming up, but there's a fishbowl session on later this week. But I think everybody knows if you're familiar with Swift at all, one of the cool architectural features is middleware and the extensibility with middleware. In fact, if anybody caught Christian's talk in Paris, I think you go find it on YouTube. It was so cool. He basically wrote middleware for this session that during the session wrote this little piece of middleware that did thumbnail storing and retrieving. It was really cool. But there's a spec right now that IBM has proposed that we're going to start digging into later this week on storelets. And long story short, it just really gives Swift the ability to more dynamically accept new pieces of middleware in different languages and run them in more secure ways and run them on proxy and object. And I just encourage you to go take a look at the spec or come to the session later, because that's going to be another really cool feature for Swift, along with another 12 things that are up there right now. Yeah, one of the new pieces of work that's been started is putting in place encryption for data at rest. And so while everyone's been kind of like really busy on erasure coding, Jamie Richling from IBM has been in stealth mode, moving that work along, which has been great. And I hope we see a lot more activity on that during the next cycle. I think I've already mentioned it. I'm working on some container sharding. There's a proof of concept out there. There's a spec. There's going to be a work session on it later. So that stuff's going to be kind of interesting. I think later on this week, we've also talked to some people with some kind of some tape back end stuff, which will be for colder storage and with perfect use for storage policies there. So yay, storage policies. So another thing that I'm really excited about, and you know, we're really just getting this started now, some long time swift contributors at Rackspace have been working on a re-implementation of the Swift object server in Go to experiment with some different sort of characteristics that you get in some different languages. A server that's marrying network, a network IO to disk IO in trying to do a pair efficient parallel IO is a really good testing ground to sort of experiment with some of these things. And that's going to be happening during this development cycle on a feature branch. We're all currently sort of investigating that and looking into the value that that's going to generate. We're looking forward to Rackspace's leadership there. I see a few of them back there. So that'll be coming up too. Lots of exciting stuff going on. Yeah, I think there are a few more specs that we are going to discuss at the end of the week, which are really interesting. So for example, we're also looking about external search, metadata search engines or notifications. And most if not all of these topics will be discussed at the end of the week. So if you're interested in contributing or helping out, please feel free to to meet us there and discuss the stuff with us. So one thing that I really like about the community and kind of how we figure out what to work on and it's kind of come up with several of what you've said already is that a lot of the stuff that's worked on and a lot of the people who are getting involved are actually themselves responsible for production swift clusters. If not directly then still very closely related to it because maybe their customers are directly running those and they've still got to support that. The point is that to a large degree all of the requirements about what are we going to work on and how does this work and how do we make sure that it works better and do that comes from production clusters rather than just some R&D labs in place. And I love that about this community. So I am curious about what might be one of your favorite production use cases that you've come across where Swift is being used today. How about digital film tree man? That was awesome. That was awesome. That's a huge stuff. You know I feel like you know a lot of the a lot of times when people are talking about what they're doing with OpenStack very often they're coming up with OpenStack Swift. So love to hear that. Yeah, very good use case I think so. Direct to introduce our company production. So in our operational company we have developed something maybe six or seven petabytes cluster for Mary Backup backend. So for backups? Yeah, Mary Backup. Yeah. So that's very excited for me because yeah, Swift can use for the production case I think. I think where Swift really shines is when it comes to global replicated clusters. So as we saw with digital film tree or with entity or many other customers as well having the ability to start data in different locations. And it's especially important for backups because you want to ensure that your data is not sold only on one side but also for applications like file sharing or data sharing inside your company because it enables your company to keep the control over your data. You know where the data is stored. It's under your control. It's not somewhere. You know where it is stored and it's that it's really important to many, especially larger enterprises that have to to keep up with regulations and so on. So being in Germany yourself, that's something that's huge there. Yeah, definitely. So yeah, I think that's were you going to share one to people or not? No, I can wait. Okay, that's fine. So those I kind of wanted to move on a little bit. So, okay, great. This is we're all great. We all love each other and we all love Swift and everything. So let's let's ask some of the some of the harder questions. So right now in our community, what's what are some of the challenges that face the community? What are we what are we fighting with? It's we haven't yet solved kind of community wise and that we need to work on. We need to schedule our next hackathon. So we have to we have to get that done. We're working on it. We've got two fighting offers right now. You'll see. Okay. So I think this probably on everybody's minds is this plethora of work that we've got a lot of just fantastic ideas. I've rattled off several more already probably a million miles an hour. So I don't know you can slow this down later and hear them. But you can go look at our specs, right? We've got how many? Anybody know the count? At least 10 or 12 specs? There's something like that. 12 or 13 and and all of them are really interesting. So, you know, to be able to pull off another miracle like what we've done with with policies and EC meaning gigantic projects without adding technical debt, without turning the code base upside down, without killing each other to be able to do that and pick the right ones and continue to repeat that process. I think is going to be our biggest challenge. Yeah, I mean, yeah, we have to admit that there there is a finite bandwidth. I think there's some overhead of doing global collaboration. It is sometimes it is challenging poor Alastair staying up late at night so that we can, you know, sync up in the mornings and stuff. Kota wakes up at four in the morning meetings. Yeah, there's definitely some overhead there. And yeah, I think we also need to manage growth. You know, we're definitely trying to bring in new contributors. There's a few up on stage that haven't been around as long and we're really lucky to have them. You know, so I think that is something that we need to keep an eye on. So how do we keep people engaged that have been around a long time and how do we bring new people in so that we can sort of manage that bandwidth growth. But the fact that it's open source, you know, we can have a company like Intel working on storelets and they can kind of do that work parallel while other initiatives are being managed by, you know, other people where they have a tighter vested interest there. Yeah, and I just think as we as we do that, as we work on new features and merge them in, you know, as we said earlier, Swift is really stable. And I think the community has done a great job of making sure that is the case in the past. And we, you know, we're charged with making sure it stays the case as we go forward. So I think maybe, you know, we need to think about, you know, our testing infrastructure some more to every time you have a new feature, a new kind of storage policy. And this question is there about are we are we covering that in our tests? Every scenario, every configuration possibility being covered in in testing. That's a great point, Alistair. I think actually in this cycle, we got to see a little bit more leveraging the Swiss stack community cluster. And we need to keep doing that. There's the infor team has done an amazing job, given us a framework that we can plug in and bring in other testing equipment and other running other scenarios off of Jenkins jobs that we have more control over. And we need to continue to build on that. That's a great point. So we're not in the community side. What about on the feature side on the technical side itself? What are what's the biggest gap in Swift today? Surprise question. I told you about this yesterday. OK, so I'll throw one out there, which is it is one of the specs we have. And I guess it's one I wrote. So. So I think being able to. Make it easier for people to reconfigure the scaling. So we have this ring partition power parameter in Swift that basically determines the scalability of your cluster. And so we have some ideas about how we can make that something that can be more easily changed. And I think that will really benefit operators and people that want to go and try out Swift, but then grow it in scale. Is there are there are some things you want to specifically improve for operators who are running the clusters or end users who are actually consuming the storage? I mean, I guess that's a good example there. But yeah, I think I think that one's a great one, right? Like from ops kind of background, you know, it's like doing the Linux LVM thing, right? Like at the moment when you're setting up a Swift cluster, you tend to try and pick how big your cluster is going to be. And so you pick this power but to be able to start small and be able to raise it. If this can get the spec working like automatically with live while while Swift is up, that'll be a big win for all ops. I mean, it makes life so much easier. I think that was a huge challenge when Swift was first open sourced and first put into production. Like the initial use case was multi petabytes and, you know, multiple racks of gear and all this kind of stuff. And since then over the last five years, we've continually tried to figure out, well, how do we do this with just three boxes? Or how do we do this with just one rack of gear and things like that in addition to continue to allow it to scale to, you know, thousands of servers and tens of thousands of hard drives? Yeah, I think there are a few, well, smaller issues that we need to fix. So one is the increasement of the ring partition power and the other one is container shedding. These are things we are going to we are working on because we want to get out of the way, right? I mean, we want to make it as easy as as possible for users and operators. They shouldn't be forced to think about things like this in advance. I mean, if you're using other very popular object storage around the globe, you don't have to do that as well. So we should probably do the same and get out of the way of the users. And so last question before we kind of open it up to the audience. Where what do you want Swift to look like in three years? Where I mean, like kind of like a more than just, well, what are we going to do between now and Tokyo? But longer term, two, three, five years from now, what do you want Swift to look like? I want Swift. If you take all of the Swift deployments in the world and add them up globally, how many hard drives, how many bytes is actually being stored that were bigger than Amazon, bigger than S3. And maybe that's a five-year goal. But like we're the open source thing. I think anybody can come out there and put up Swift. And we, you know, in every data center, these should be the larger storage deployments that the administrations are putting up, unifying storage across all the platforms. And so it should be where it's all the all the all the bytes. Yeah, you know, along those same lines. And this ties back to what we're saying earlier about working in this community. One of the really cool things is I think a lot of us take a lot of pride in things like the digital film tree presentation today or in Hong Kong, the Mercado Libre use case. So, you know, it's really cool to see stuff that we're working on out there in production, making a splash and other people are proud of it. And we all have a piece of that. So I think where I'd like to sit in three years, I'd like to see more of that. I'd like to see more household name kind of stuff. Like I think Ancestry's got a thing that at this week, right? Using Swift. I want to see that like just commonplace. Everybody up. Swift is there. Swift is there. Swift is there. So along those same lines, but I like the publicity. It makes me feel proud to be part of this team. I want... Did you know that the last James Bond movie was partially used? Swift was used to help do the special effects on that? I did not know that. Thank you. Just me. So I want more contributors and the user in Asian time zone. The channel gets a bit lonely. It's like Australian and Japanese like we're holding down the fort. So more Australians, not that I think anyone's here, who's a really Australian. Oh, no, Michael. Come on, Australian. Come on, let's bring up our time zone. What about you, John? What do you want to see Swift? I mean, you're supposed to be thinking about this sort of stuff. So. So one thing I've said a lot of times, Clay, and you've told me I've said it too much is very much along the lines of some things that Clay and Paul said is that my vision for Swift is that everybody will use Swift every day, even if they don't realize it. It's just like everybody every day, everywhere. So if you're going to help your kids with homework, they're going to be using Swift to do that when you look up stuff on Wikipedia. If you're going to be watching movies and you're looking at stuff like digital film tree and Comcast, streaming that many movies to you coming out of Swift, that's there. If you're playing games and you're downloading stuff on the internet, it's that stuff is sourced and stored in Swift and delivered to you through two other things. That's the kind of stuff is it being ubiquitous for the storage. One thing I remember Clay said probably over lunch some time a few years ago is just like, look, if you're storing data on the internet and you're not using Swift, you're doing it wrong. And so that's the kind of thing. Yes, I want to see it go more and more things. Some of the stuff that I'm really excited about and one of the things I really want to see in like a specific thing is kind of the cool stuff that's coming along with new storage media. So we've seen things that in the past several summits, Seagate's been around talking about their new Kinetic Platforms key value hard drive. You've got other spinning media technology like the SMR drives that kind of a different way to go denser and you give you like 10, 12, 14, 20 terabyte hard drives. That's pretty interesting. And then here this week we've got a couple of different companies who have already released some codes and third party ecosystem code that lets you run Swift on top of tape libraries. And that's really cool. And then there's also the whole world of flash. And it's a whole new way to do things. And so what I want to see is that natively when new storage media technologies are released and developed, that Swift is already supporting those and can take advantage of all the particular characteristics, everything from tape to flash. And so when we do that, that gives the deplorers flexibility that brings a lot of value to the end users who are actually doing stuff. And that's kind of what I'm really excited about looking forward. So so I think we have a few months, a few minutes left. So I would love to answer your questions. What do you have questions for us with things? There's a mic over there. Would you mind coming up? Yeah, hello. Oh, yeah. Yeah, it's OK. Yeah. Tail from the SKHMS San Jose. My quick question is for your daily walk when you write the code in terms of testing, especially if you have to deal with some of the scalability issues, how do you test it? I mean, sometimes like a scalability matters. And then maybe the only that can that the same problem can happen only in some of their mass scale customer environment to use some simulation environment you have to submit to the code to the end user and then for them to validate, I just wonder how you deal with that kind of scalability testing issue. That's that's really hard. I mean, there is some things that you don't necessarily see until you until you are running them at scale. And so, you know, being having that feedback loop with the the operations team is really important. But there's a few things that we can do and Swift can really leverage this with a lot of experience. You can you can kind of devise strategies that you that you are sort of known in scalable approaches. Swift will often take the approach. I think in our design principles, we talk about leveraging the economy as a scale. But the idea is if you can do something like three times on a bunch of nodes, that's that's the best way to do it. You know, like don't try to necessarily do a lot of coordination and bring everything and just just make sure that the system is is able to achieve the end goal, even if that means in sort of the failing degrading case that it's duplicated work. And that that's one of the strategies that you can employ to scale. Just avoiding contention, trying to segregate things into, you know, smaller blocks. You know, the the reason that we're looking at container sharding now is because there is this, you know, where we didn't want the containers to be a point of contention. So you make it so you have as many containers as you want. There's no hundred bucket limit kind of thing. So being able to break up problems into smaller pieces helps. But as far as testing, I mean, a lot of times it just takes somebody that has a concern about a scalability or specific component, bringing it into the lab and trying to, like you said, simulate it under some serious load on a more constrained, you know, six or ten note environment, something like that. Yeah. Or more, even. I think one of the things that's really cool is that we've got people in the community here up on stage and also other people in the community who are actually running very large clusters. And so we can. We're not going to. One of the things that we're going to do is if you submit a patch that's going to have a question about that, we're not going to enable that by default for everybody. So that allows somebody to put it into a lab that has a few hundred machines, even at, you know, places like Rackspace and stuff like that. And they could actually test it and see what happens. So that's really kind of cool is being able to hear from people who are already running at very large scale and let them kind of tune a knob and see what they think. Thank you. Hi there. I'm Vishnu from NetApp. So it's kind of a hard question, but just want to get your perspective. You know, you have a bunch of vendors today who are building their own Swift implementations and you have Ceph that's also implementing Swift. And there's that whole API versus implementation, right? And you guys are just another implementation, but also the reference API. And I'm trying to understand what's your perspective on, especially given that the APIs could fork, right? And Ceph already is forking parts of it. So they have unique containers and you guys don't. So I'm just wondering what's your perspective on implementation versus API, especially with commercial vendors and other open stack options? That's actually a really good question. Something that does come up a lot. I'm actually kind of happy you brought and I'm kind of sad and kind of happy that you asked that because it's one of the things that comes up a lot in the hallway tracks and conversations and kind of behind closed doors. So it's great to actually say something publicly about it. I think there's two important things. My perspective has two components to it. One, absolutely firmly believe that implementations matter. And just saying that an API is this document someplace that describes something is not sufficient because the actual nuances of the API and how it's consumed and the performance and things like that matter just as much as the actual, what are the verbs and the parameters and all that kind of stuff. But the second thing that I think is really important is that once you say that, okay, it's API and the implementation matters, it comes back to the whole reason behind open stack. And to me, the important piece there is the open. And the fact that we have an established open design development governance model, all of that sort of thing put together and that if something is done under that model, then it is part of open stack. And so if somebody else is going out to reimplement an API in a different way, but they're not doing it as part of this community right here, all of us here in this room and all of this in this building this week, then I can't really comment on that. I can't really have any real opinion on that because it's completely external to what's going on. If it's not brought to the community, then it can't really be treated as the community sort of thing. So I'm really happy that people have found this and said, look, this is a really great way to do object storage. This is a really great way to talk to object storage and encouraging the development of applications and because that's what it's all about is people using and consuming the storage with applications is really important. And I'm really glad that people out there will help promote that. But absolutely, I strongly believe that the way you do that is in the open and the established way that that is done today is through OpenStack. And so apart from that, I would say, well, that's not OpenStack. That's not Swift because it's a reapplication of some part of the Swift API. But if you actually want to get involved and you want to make things better for everyone, then the way to do that is part of the OpenStack community. Does anyone have anything to add to John? I thought it was pretty eloquent. We talk about this kind of stuff a lot. I mean, we love, you know, more people who want to implement the Swift API, the better. You know, we think it's a pretty decent API. OK, great. And a simpler question. What's the one big thing among the specs that you have that you think customers are asking for? I think the encryption is something that is a very popular topic and a lot of times it's because that's something that's visible on the end user side. So there's a lot of people, especially as Swift is getting deployed more and more with... We've got several people here this week talking about storing genomics information, which is almost the definition of personally identifiable information. So they want to encrypt that kind of stuff, financial documents and stuff like that. So I think that's probably the external facing most popular thing. We were just flagged down. I think we have time for one more question. Yeah, it's kind of about the way that Swift fits in with the overall open stack infrastructure in the face of the blurring of distinction between compute and storage. So we're thinking about things like, you know, what's it called? The Lambda function type API for the other people have. And then there's also the... Somebody was talking about Storlitz and where does that... How do you provision the compute that sort of implicit to the storage? That's kind of the question. ZeroVM's been working on that too. I mean, I think a lot of people have been looking at these large-scale storage clusters and, you know, they're busy working on their storage problems, but I think people also want to apply compute to their data. So, yeah, yeah, maybe that. I don't... I think that right now, the people are really just, you know, like Swift is mainly a storage platform. So I think that what we're seeing with Storlitz and ZeroVM, these are new kinds of experiments that people are kicking out. And I'm pretty excited about them. But I think for at least some time, they may be separate from the primary storage platform as people are sort of proving them out and figuring out how to scale them and what's the different sort of hardware characteristics that you want for these sort of compute and storage clusters. But I think it's really important sort of for technology in general to leverage that. Yeah, and as I see more and more people starting to use Swift and at bigger scale, I think a phrase that was bandied around a while back is that scale demands specialization. So if somebody is going to say that, you know what, I've got an exabyte of data to store, generally you're not gonna build that out on hardware that also can do a whole bunch of compute all at the same time. I mean just like power wise and cost wise, marrying those together that the hardware, you want to specialize on that to actually save some dollars. And so what I see quite a bit of is people saying, look, I've got a storage problem and this is a really good one and it's gonna be cheaper and it's gonna be easier to maintain and easier to deploy and manage over time and scale. So that's why we're gonna use Swift and so that's what normally the kind of things that I hear are. But with the storage policies and new ideas for data migration, like I mean it's all gonna get unified. Yeah, it's pretty cool stuff. And policies could easily be part of that provisioning answer as well, right? If there are concerns about compute utilization in the cluster, you could easily segregate the platforms that are dedicated for something like a storage activity and often it's own policy. I think we're out of time. So thank you very much for coming by. All of us will be around this week. Feel free to give any of us at any time to have any questions. Thanks.