 with the OpenStack Foundation and the Mataka Design Serious Conversation. I'm here with John Dickinson, the project technical lead for SWIFT. John, thanks for joining us and tell us a little bit about yourself. Good morning. It's nice to be here. Thank you for posting this. As you said, I'm the project technical lead for SWIFT. I've been part of OpenStack since it very first started. I was on the original development team for SWIFT. I think that gives me about six years of experience inside of an OpenStack project. For the past three and a half years I've been working here in San Francisco at SWIFT. Tell us what were the hot topics that your team discussed in Tokyo and what were the decisions and outcomes from those discussions? We had a great design session in Tokyo. We had a great week where we get together. We've enjoyed the summit weeks and any kind of other in-person meetings we have with the global community. It really is a place where we can get this really super high bandwidth communication, figure out what's going on, what are the pain points that people are talking about, get a status update and some more design decisions as far as things that are ongoing. So as far as some of the big stuff we have going on, one of the most popular topics that is not a new topic, but something that's been in progress for probably a little over six months now, most of this calendar year, is encryption. And so we're trying to implement a way that operators can encrypt all of the data that is stored in the cluster so that it meets certain requirements for certain deployments, especially those where they're storing personally identifiable information, financial records, things like that. These are places where people are really starting to embrace and adopt SWIFT and some of these new use cases have additional requirements. And so in order to lower the barriers for adoption, it's one of the things we're currently working on. We also spent a lot of time on following up with erasure codes. As you know, something that we've been working on for a while, we were released that originally back in the spring. And now, throughout the past six months, we've been testing and deploying and really evaluating and polishing that feature. And we've made some great progress. We've got some great results. And so we were kind of sketching out, okay, where are we now and what do we have left to do on that? We had a great feedback session from operators. And one of the things I like to do inside of the SWIFT Design Summit Tracks is have an explicit session set aside for operator feedback in addition to the other kind of feedback things you can get with the operators track. And we've got a couple of interesting requests this time, specifically around utilization and kind of what the hardware resources are doing around how specifically disks are being used and some more information exposed to operators along the road line and also some better ways to facilitate the different ways people have implemented utilization tracking inside of SWIFT. And I think that one of the other big things we talked about is how to work inside of or improve the SWIFT client, both the SDK and the CLI tools, so that applications can better use and consume SWIFT, so it's perfect for storing application data when you're dealing with applications that are being deployed at very large scale, storing a lot of data, these web and mobile apps and things like that. And so we want to make sure that we can encourage the applications there. And so we've got some work that we are evaluating starting, designing to improve the SWIFT client, the documentation around that, and working more closely with Keystone for people who are using lots of different open set projects and improving docs for people who are only using SWIFT. So during the talk of planning, what did you identify as the user needs or problems that you're trying to solve? One of my favorite things about the SWIFT community is that nearly every single person who's contributing code to the project is also responsible for maintaining production clusters. And as such, when we're developing new features, when we're figuring out what are the new use cases that we need to start to support and the barriers to adoption that we need to remove for existing use cases, the specific user needs are intrinsically tied to the things that we're working on. We're not going to go out and spend a huge amount of effort on encryption or erasure codes or something like that without there actually being people out there ready to consume it today but simply not being able to because it's not yet ready or not yet available. And so I would say that what are the specific user needs that were identified? It really just comes down to the same things I was talking about earlier. What are the big things we're working on? Because each of those are tied to specific use cases and specific requests from both end users and the deployers and operators who are responsible for maintaining things in production. What features, maybe three or four new features or enhancements should we be looking forward to in the talk of release? So I think the biggest thing that we're spending time on that is probably net new is encryption and being able to support that. One thing I've always been very careful about is to not give specific dates as far as this is going to be done at this particular date because one of the joys of open source development is that you actually can't really control that as people come and go and have different employers moving people around to get to work on different things. But encryption is something that we're spending a lot of time on. One of the other things we're spending quite a bit of time on in various ways is improving the overall experience for end users and operators specifically around lowering latency and smoothing out latency when clusters are under load and giving the operators the tools they need to have the right insight into that and to more efficiently manage their clusters. Great. Thank you. And then one last question for you. The product work group has a number of themes that help kind of connect the dots between various projects. Those themes include scalability, resiliency, manageability, modularity and interoperability. And I wanted to know which of these themes do you feel that what is contributing the most to is really focused on? Our number one priority is all of those. Obviously that can't be the case for anybody. But I will proudly stand behind the work that the community has done over the past six years in specifically around scalability and performance and being able to have a system that scales to massive levels and is usable by people of all different deployment patterns. But that being said, we are continually working on improving that wherever we can so that specifically as I mentioned earlier, dealing with internal cluster data transport, for example, is that when there's failures that we're automatically working around and we need to move data around inside of the cluster, whether it's capacity adjustments or things like that, we want to make sure that we're doing that the most efficient way possible as quickly as possible because that makes operators happy and ultimately gives a better user experience for the end user. Some of the other things that we're currently working on are better interoperability with Keystone. We, of course, have been supporting Keystone forever, but one of the things we're looking at adding on right now and there's a lot of interest around it and some development work already is adding in Keystone policy support so that they can have more of that role-based access control that's already supported in some other projects. So we're working on that sort of thing and I think that's kind of how we apply it for those things. Well, John, thank you so much for joining us. We appreciate it. We're looking forward to being slipped into the talk early. Thank you very much.