 Hi, this is Pete Chadwick. I'm from Sousa. I'm here on behalf of the Product Working Group of the Outlook Staff Foundation and today I'm talking with Ben Schwartzlander who is the PTL for the Manila project which is shared files as a service and we're here talking today to Ben about what's going on with Ella and Newton. So Ben if you want to just introduce yourself to the team, give us a little background on what you do, who you are. Okay, hi I'm Ben Schwartzlander. I'm the project team lead for Manila basically from the beginning of the project until now the Newton release cycle. I work for a net app in RTP North Carolina and I'm a principal engineer as well as an open stack architect. Okay and what are some of the highlights of the things that you have that you have been working on as part of Manila for, well first of all why don't you start off by telling people a little bit more about exactly what Manila does. Sure, so Manila was created to add shared file system storage to OpenStack. It's analogous to the Cinder project but it provides NFS exports, SIF shares and other shared file systems instead of block storage. So it's a compliment to Cinder in terms of storage. And what were the, at the recent Austin summit and through the various meetings you've been having, what are the hot topics that your team was trying to address at the design summit and sort of what are the outcomes of those, were those topics, of those discussions? Yeah, so I would say the main topic in Austin was discussing what it's going to take to get some of our currently experimental features to be officially supported. For example, we have shared replication and shared migration are both currently implemented in the Mitaka release as experimental features and we'd like to get them to be generally available. So the thing that we focused on was what are the gaps that we have to address before we can officially support these features. For example, shared replication doesn't yet support secure multi-tenant configurations where we use shared servers and shared networks. It currently only works in a no-share servers driver mode and the shared migration doesn't currently support any optimized migration path. We don't have any back ends that have implemented that. So that's something that we need to implement and test in the Newton release. We hope to address both of these gaps and get those features to be generally available within the Newton timeframe. And from an end user perspective, what kind of problems will those features help address? So the shared replication addresses sort of a disaster recovery use case which we hear everyone talks about. In fact, there are several new projects focusing on the disaster recovery area. So, shared replication is specifically designed to make it possible for end users to control the replication of their data and to control the high availability of their data to protect themselves against outages, even outages of an entire availability zone. Replication protects you against that. Shared migration has all kinds of applications. The initial implementation is just the basic support for administrators to move shares around from one storage controller to another. But in the long run, we hope to provide an end user facing interface on top of shared migration to allow people to do retyping, migration between availability zones, migration between data protocols perhaps. There's all kinds of changes users may want to perform on their data that all boil down to migrations internally. Okay. What would you say the top three priorities for new features and enhancements look like? Yeah, so as I mentioned, from what we discussed in Austin, the top priority is to complete all the experimental features. We don't want to have work that's half done and not implemented, so we're prioritizing completing things that have already been started over starting new things. There is one new feature, which is really compelling, which was proposed by Mark Koder, the Hierarchical Port Binding Work, which will allow back ends that use VLANs to segment different tenant data to plug into Neutron, even if you're using VXLANs on the Neutron side. That's really exciting to be able to bring that to Manila so that you can actually stitch your share networks into your Neutron network seamlessly, even with back ends that don't natively support VXLANs. Test coverage and improving and maintaining quality is very important to us. In fact, we're developing a new container-based driver specifically to help us improve our automated test coverage of share servers and secure multi-tenancy. We're increasing the scope of our scenario tests and increasing the scope of our third-party CI requirements to ensure that we maintain a high level of quality. Okay, so would you say the themes were on stability and manageability for the most part, was where you're focused right now? Well, yeah, I guess it depends on how you look at it. Stability, resiliency are related to the quality that we're trying to drive. We are starting to lay the foundations for high availability. It's something we've wanted to do for a while and as we've looked at that feature, adding a true high availability solution for Manila itself is going to require some architectural changes that'll probably spend multiple releases. Some of that will start in Newton, but manageability is also a theme for us. Getting UI coverage for all of these new features. We've implemented new features. We don't necessarily have them showing up in the horizon interface. That's part of completing these new features and making them generally available. Getting the user interfaces implemented. Okay, so can you look forward a little bit to talk about where you think the focus is going to be during the Ocata cycle too early? Well, the theme in the past has been that we typically carry over a lot of work. As I said, we hope to wrap some things up in Newton which will hopefully leave us more bandwidth to start new things during Ocata. As I mentioned, high availability of the Manila service itself is going to require some architectural changes that will span more than just one release. So hopefully if we make enough progress during Newton, that's something that could be delivered in Ocata and we could have true availability of, you know, high availability of all of the Manila services with redundant copies and similar to what other OpenStack services have done. Okay, I guess that was kind of the wrap on specific questions I had. Is there anything else that you think that the broader OpenStack community should understand about what you're trying to do with Manila? Yeah, I guess one of the interesting things about Manila is it was probably one of the first projects to be added to OpenStack after the Big 10 theory was established. And so that means that, you know, we have integrations with projects like DevStack and Tempest and Horizon, but we're not integrated in that we're in those projects. We have plugins to those projects, unlike Nova and Cinder and some of the original OpenStack projects that are simply integrated directly with those. So we have some unique challenges in terms of how we integrate and because we're sort of farther along on these integrations than a lot of other projects, we're sort of bumping into some problems with how do we keep our tests stable as Tempest changes? How do we keep our UI from breaking as Horizon changes? We need to interact with the rest of the community and find solutions to these problems and we're looking for new contributors to join and help us address those those kinds of problems because Manila is kind of unique in our position as sort of one of the first projects to join under the Big 10. Okay. Great. Well thanks for spending the time and we'll look forward to seeing what comes out of the group over the next you know over the the rest of the Newton's pipeline and looking forward into OCOT.