 Good evening, everyone. Welcome to the last session of the day. Thank you all for being here. We understand we're standing between you and the beer and the barbecue. So we appreciate you all being here. This session is on Manila, shared file system management. If you think you're in the wrong session, now is a good time to turn around and run away. Jokes apart, the logo on the top right was launched this week, so this is fairly new. It was voted in last month. And it was selected. So this is the official logo for Manila. I do have stickers here for that logo, in case you want to grab some for your laptop and your desk. I also have a few other swag from the NetApp booths. With solid fire printed on it as well, if you wanted to grab it later. So we'll start off with just a brief introduction about the presenters. My name is Anika Suri, and I'm the technical alliance manager for the OpenStack ecosystem at NetApp. And I have here my colleague, Cameron. Cameron Steeder. Let him introduce himself. Yep. I'm a technology strategist for SUSE. Thanks, Cam. So moving on, just a quick audience poll. How many people actually have used Manila here? Anyone? OK, just one. OK, perfect. This is a perfect audience. So we'll cover the basics. We'll try and go into depth as the time permits. And please feel free to ask questions and answers in the end. Those are more than welcome. We'll briefly start off with, so Manila is kind of named after the city in Philippines, right? You must have heard Manila in that context, or you must have heard the Manila envelopes in your filing cabinet, right? We're going to talk about Manila in the context of OpenStack. So we'll briefly talk about what exactly is Manila, because there's only one gentleman here who knows what it is. Why would you want to use Manila? We'll talk a little bit about the use cases. My colleague, Cam, will cover a little bit of the Sahara integration with Manila as well. We'll talk about the Metaka updates, which is the latest release. We'll talk about the distributions, and we'll show you a demo on NetApp Storage with Suze Cloud 6, which is their latest release. And we'll talk about what's upcoming in Manila in Newton. And then we'll take question and answers in the end. So starting off with what Manila is. Manila is OpenStack shared file service program, and it supports multi-tenancy. And what it does is it provides secure file share as a service. What that essentially means is that you could have, for example, a 5-gig NFS share, right? And you could share it between different tenants, and that too securely, which means you could have different departments, such as your sales, your marketing department, and both of them will be able to share the same file share securely by you providing a network range on who has access and who doesn't. So Manila for file share is kind of similar to what Cinder is for block share, if you guys know the Cinder project, except there's a tiny bit of difference. Manila has this networking component that I just mentioned, which is why there's a little bit of more magic that goes into Manila than Cinder at the back end. So as we saw, there's only one person in the room that really knows what Manila is. These are going to be key slides for you to actually understand the concepts of Manila. We're going to be referring to these terms later in the presentation as well. So please take note of these terms. Share, of course, we already talked about it. It's an instance of a shared file system. It can be accessed concurrently by multiple instances. ACLs, which are access control lists or shared access rules, they define what the clients can access in the share. And they're usually given by an IP or insider notation. That could differ based on what you're trying to do and what drivers you're using. A shared network, that defines the neutron network and subnet through which instances access the share. Security service, it's a finer-grained client access rule authorization, such as LDAP. Snapshots are read-only copies of shared contents. And back-end and driver, every vendor has their own back-end and every vendor has their own drivers. Back-end is basically a provider of shares. And the share resides on a single back-end. And the driver is basically vendor or technology-specific, of course. And it's technology-specific implementation of the back-end API. So now we move on to a little bit of the history. Manila was first introduced back in the Atlanta time frame in 2014 when it was first introduced. And since then, it's only grown. It's got a lot of traction. There was no stopping Manila. It was officially introduced as a core service in the Kilo release. And there were a lot of important features that were introduced in that release. For instance, storage pools was one of them where you could have different pools instead of one big pot. You could have different pools of different kinds of storage. For instance, you could have SSDs. You could have disks, spinning disks, and instead of one big pool, basically. And then, for instance, also in the Liberty release, we had a lot of other good features, such as consistency groups. And Cam will be talking more about availability zones and other features. But consistency groups is when you want to combine the shares based on consistency for data protection. You can do that. Manila gives you that capability. So moving on to Manila today. So the latest OpenStack release, as you know, is Mitaka. And Manila today, we'll just talk briefly about the number of drivers it has. Currently, it has about 18 drivers, which is an increment from the last release. The blueprints completed in this cycle were about 43. This number is a little down from the last cycle, just because there was a lot of time spent in resolving bugs. You see the stats on the right. So there were about 232 bugs that were resolved. And then the major blueprints that were covered were, for instance, share replication. I list a few of them here. But Cam will be covering these in detail, because we'll talk about what's in Mitaka and what's up coming in Newton in the future slides. So before we move on to other things, I quickly just want to cover Manila operation and deployment options that you have with NetApp. There is a Boolean variable, which is called driver handles share servers. And this variable is set in the Manila config file. If this variable is set to true, that means that the driver will handle the share servers. And if it's set to false, then it won't. You're kind of on your own. For the deployment choices with NetApp, you have two choices. One is direct and one is indirect. Sorry, one is intermediated. With direct, the Manila driver is directly going to talk to the NetApp FAS storage. And in the intermediate one, there is a software entity in the middle that takes commands from the Manila driver and then passes it on to the FAS systems, or AFF, or any other NetApp storage for that matter. And then in the network plugin, you have three options. You have a standalone. You have a NOVA network. And you have Neutron. And all of these plugins will support the segmentation that the network supports. So for instance, Neutron supports VLAN segmentation. So that's what the plugin is going to support when you use that in conjunction with Manila. So moving on, the good news is, not for the good part, the good news is that we have about 14 entrants in the Mitaka release. Congratulations to them and a very welcome. Thank you again for contributing to the Mitaka code. And we have a few good names are Erikson, Walmart, SAP, EZStack, AT&T. So there have been a lot of good contributions. NetApp does lead the code contributions currently. And still, NetApp kind of pioneered in this project. And NetApp is about 28% of the code contributions, with Sose being at about 4%. And even in code reviews, our engineers contribute heavily. So even in the code reviewing, NetApp pioneers. And we have about 32% of the share with Sose at about 4% again. All these stats are available on Stackalytics. That's where we got them from. And these slides will be available to you later if you want to review them or keep them for your record. So we covered a lot about what Manila is. But now it's the question, right? Why Manila? We talked about what it brings to the table. We talked about multi-tenancy. We talked about security, how it provides a secure file share, right? And of course, this helps you bring down the cost as well. Because there are a lot of other methods that you can use for file share. And if you use Manila, which is open source and part of the OpenStack project, it definitely helps you bring down the cost of your deployment. And IDC has, of course, every analyst has their own thing, right? IDC suggested that this is the age of cloud file services. And the number for file shares, increasingly, it's going up. And that's why the investment in file shares is also increasing. And that's why we think Manila is a really good idea. And you should all at least give Manila a chance in your OpenStack deployments. So after all of this, the question really is, why not? Why would you not want to use Manila? It's free, it's secure, it provides multi-tenancy, which is kind of the thing that you need for a hybrid cloud or a public cloud, right? Or a private cloud. And if that doesn't, it's not this enough, too. We'll go over a few use cases that will definitely make you more interested in Manila. So I'll just briefly cover the use cases. And then Cam will go into those details. DevOps, containers, Sahara, databases, the service. They are all use cases that you're probably hearing at the conference right now anyway. And Cam will cover these in details. But these are all the use cases that kind of apply to Manila. Thanks, Anika. Thanks for getting us started there. I'm really excited about Manila. And I'm going to show you why. There's several reasons why I'm excited about Manila. I'm going to talk about some of these use cases. And let's go ahead and just deep dive into some of these use cases. First of all, standalone file shares. We've been using those for quite a long time in our environment today. You have legacy systems that work off of these legacy file share services, whether they be SIFs or whether they be NFS. It could be something else, right? You have systems connecting to those. You are maintaining those file share services in your environment today. You have a set of guys that are maintaining those. Maybe you're maintaining a set of scripts that is deploying those share services across the board to hundreds to maybe even thousands of systems. Maybe you're using it on Linux systems and you're taking advantage of AutoMounter to be able to deploy those and map those into those systems. You might have other systems that are using scripts for those deployments and mounting those up through scripts. Either way, you are spending a lot of time and effort to be able to mount those file systems and those file shares on your servers. Manila is going to fill the gap there. It's going to allow you to automate that framework in OpenStack. So you can start moving those legacy environments into OpenStack. And that brings us to our enterprise applications. I had a colleague this week a few days ago that was giving a session on how to take those enterprise applications and start moving those, migrating those into an OpenStack environment. Manila is going to fill one of those gaps. What I see there, and that's what makes me excited, is that Manila is filling that gap, that need that we have for shared file services within OpenStack. You have legacy systems, enterprise applications that are utilizing those shared file systems today for your applications. You need a way to easily move those into an OpenStack environment. Manila is filling that gap for you. OK? Do we have any DevOps people here today? We've got a couple. That's great. IT people, operations specifically, all right. That's great. So the way that I want to work through this DevOps thing, DevOps is complex. And it's because of all these logos that you see here. There's a lot of pieces and parts that are working together. They're usually connecting through APIs, very pluggable infrastructure. OK? You can take advantage of this kind of infrastructure running on top of OpenStack. And the way that we can fill some of these gaps using Manila is you can use the file share services from Manila to plug in to these environments. Plug into OpenStack, plug into your Docker infrastructure, managing share file systems on top of Docker. And maybe you want your data to reside on your shared file system using a get back end for your DevOps environment. There's also analytics and containers that play a big role into DevOps. I'll talk about those in just a little bit. Manila will allow us to do snapshotting and cloning in this environment. And then, of course, if you have a multi-tier application running, you're spinning that up using your DevOps lifecycle management. You can use the consistency groups and wrap that around that multi-tier application and enable that with shared file services, being able to manage that single share instance across the entire group of servers there in that multi-tier application. I've got a couple of key DevOps tools in there. Since I'm from SUSE, I'm going to highlight those. The OpenBuild service. The OpenBuild service has been around for a long time. That automates the deployment of your RPMs, the creation of your RPMs. You can drop in your source code and it will build it for any distribution out there, all the major Linux distributions out there. We also have Kiwi. There's not a lot of people that know about Kiwi unless you're a SUSE guy. Kiwi is a free resource that you can use to create images. There's several different tools popping up all over the place. Kiwi's been around for over a decade now. And we've been able to use that to create images for a very long time at SUSE. And then SUSE Studio is a tool that runs on top of Kiwi. Gives you a nice little GUI interface for it as well. You can go out to susestudio.com and use that for free. Let's dig deeper into the Sahara integration. I've got this experimental. Now I'm going to tell you why that is at this stage of the game. There's a couple of use cases I want to dig into here with Sahara. We can use Manila to store our file shares to store our binaries and job templates for Sahara. We can also use it for storing the input data and the output data of Sahara running on top of Manila. I need a couple of ways. We can mount the NFS shares using the APIs. And Sahara will actually mount those for you. So that's fully automated. So the work has been done in Sahara in the Mataka release. That's completed. Some of this is a bit experimental. So your mileage is going to vary a little bit. So you're going to have to test some things out with that Sahara integration. There may be some pieces and parts that aren't quite connected yet. I don't know exactly where those are, but I know that there are some pieces that aren't quite working yet with some of those drivers. There's also the Manila provisioned HDFS. What that means is now, instead of just NFS as a back-end file share for Sahara or attaching Cinder or something along those lines to Sahara, we can now have Manila provision out your HDFS for you. So you have an HDFS back-end that's native for a Hadoopan environment there. So to take those use cases a little bit further, this is what they look like. On the right-hand side, we have the data sources running on Manila provisioned HDFS. So take note that one thing that is quite unique here, that it's single user, and it really is not that secure at this point. So that's something that is also missing in this HDFS drivers as well. So hopefully, that will be a blueprint as we move forward. So the other use case on the left-hand side there shows the mounting using the NFS. This would be auto-mounting from the API that Sahara is taking advantage of there. Now this could be any one of the drivers that is in Manila. Now Manila has 18 drivers now in Mataka. So it's continually growing. You're going to see newer hardware vendors coming in as well. And you're going to see them starting to integrate a driver into Manila. And I take advantage of the infrastructure that's there. So that's going to continually get better. What is new in Mataka? Let's give it a little bit of an update here. I'm going to highlight some of those things really quickly. And then I'm going to dig a little bit deeper into some of these things that have been updated. API updates. We talked about this in Tokyo. We talked about the microversions that are available now in the API. So there's continually updates there, making changes, of course, to some of the features and whatnot. We have the admin network plugin. So this is a new feature for the shared servers. It will actually create an admin network as well along with the Neutron network or the Nova network that gets created there. Quality of service is a common supported thing now within the Mataka release. And as far as I can tell, there's only one driver that's using it at this point. So one hardware vendor is taking advantage of that. There's new drivers, of course. There's four new drivers in this release. So there's going to be more coming about as well. New updates to some of the old ones as well. The HDFS native driver was worked on a little bit. Added the ability to extend the shares with that particular driver. There was a session earlier today on CFFS native driver. So you can go back and listen to the recording if you haven't seen that. There was the inclusion of the LXC LXD driver. I'm going to talk about that in a little more detail in a little bit. But it's essentially dead. The reason why is because we're taking some new direction there with LXC LXD. And so we included it. But then now it's taking a new direction. And I'll talk about what that direction is. Then there's the LVM share driver that we've included. I'll talk about that. Snapshotting, the manage and unmanage capabilities for snapshotting. What that means is we can actually now take a snapshot that's been created in OpenStack. And we can bring that snapshot into Manila and start managing that snapshot through Manila. And that is all using a new back-end feature called Data Copy Services. Data Copy Service will be taken advantage of with share migration and also replication as well. Share replication was enhanced quite a bit with Mataka. There's a whole set of new features that we've added there. Now, I'm going to dig deep on some of these features that we talked about on the Liberty release because I feel like it gives us a point to start at because these particular features go on succession here because one enables the other. So I think it's important to go back to Liberty and take a look at what we've done before we talk about some of these Mataka features. So share instances, this was needed to enable share migrations and replication. And what this allows us to do is on the back side or the back end, if you take a look at the driver, it allows us to keep a few things hidden away from the user side. So the user doesn't know exactly what's going on. Before, we couldn't make this possible because the UUID that was created for the share, the user would go in and that UUID would change if we did a migration or if we did a replication. With share instance, that UUID stays the same. So essentially, the user's not really seeing what's going on because that UUID is the same. OK? So that was important that we had that there. And now we get into share migrations. So share migrations allows us to do migrations from one host pool to another by using the Manila migrate command. This is very basic implementation. It actually has a fallback approach. So some of this was actually taken from the Cinder code, where the fallback approach there in Cinder is actually to use R-sync, which is a bit slow running an open stack and really is kind of inefficient. So if you take a look at share migrations today and how that's working, mostly on the generic drivers, you're going to see whatever they program in there for share migrations. And maybe they have some customized things that they're doing with the API, which is available. I have not seen really what the other ones are doing there. I know that they're really not taking much advantage of it there. But if you take a look at the NetApp driver specifically, they're doing a really good job of it. They're taking advantage of the share migrations here. You're going to have really fast speeds with the share migrations running on a NetApp environment. Availability zones, this is really important. This is a really great milestone because we're taking this feature from Cinder. And we're essentially reworking that into Manila. So this is giving Manila that same capability of having availability zones in Manila. That came into the Liberty release. And I'll talk about why that's important here. Allowing us to preserve the availability zones, preserve our shares within each availability zone, be able to migrate from one availability zone to another, it gives us that high availability that we need in our Manila infrastructure. So we can migrate from one zone to another or within the same zone. Share replication. Share replication is going to give us some non-disruptive operations. Now this works in conjunction with availability zones. So you could have multiple zones that are replicating to each other through these availability zones. The failures will happen within either a single availability zone, depending on how you have that set up, or another high availability solution would be having clustered storage on the back end with clustered data on tap from NetApp, where you can actually fail, fail over an entire availability zone to another availability zone. And that's really only working well in the NetApp driver. This is not something that is really taken advantage of in a lot of the other drivers. Now this is one I wanted to highlight because this one's really good for testing. If you're standing up a new environment and you really want to play around with Manila, kick the tires with it, this is going to give you a lot of features to play around with to see how it works out and you can kind of test it out and play. So you can go in, you can manually create your physical volumes, your volume groups, just like you would any other LVM environment. So it's really familiar and it'll be easy to really play around with. You have the ability to sift and NFS shares with it, create and delete snapshots, create a share from a snapshot. So that's all available through the share manager in Horizon. It also takes advantage of the mirror capability in LVM, which is kind of interesting and that's what I'm diagramming here on the right-hand side is that mirroring capability within the LVM driver. So you can have physical volumes that are mirrored within this infrastructure. Maybe this will get a little more solid as time goes on and you can start using this in production, but I wouldn't recommend it at this point in time. It is a bit restricted. So if we take a look at NOVA, the maximum number of virtual PCI interfaces is really where that restriction comes from. It's limiting us to 26 shares per share server. So when you spin up a share server, you can only do 26 shares. So that's a pretty big limitation. So let's move on to talking about SUSE OpenStack Cloud and where we integrate with Manila. Now, the Manila service was introduced as a technical preview in SUSE OpenStack Cloud 5. And that was the Juneau release of SUSE's version of OpenStack. And now we are at the... Our new milestone is version 6, which is now fully supporting Manila. And most importantly, we're fully supporting the NetApp driver in Manila because we feel like it is the most stable of all of the drivers there. If you take, for instance, if you're a storage guy, any storage people here. So if you focus on... If you focus... If you're a storage guy and you focus on the different tiers of storage that you have, you've got zero through three, right? And at the top, you have high-performance storage. You know, you're really not going to get that high performance unless you're using something like NetApp and plugging that into your Manila infrastructure. You're not going to get the high performance that you really need unless you're using that NetApp type storage. We have a tool called Crowbar that does our deployment framework. Crowbar will deploy the Manila infrastructure. You go out and you define a few parameters. The host's name of your cluster data on tap infrastructure and a few other parameters, and you hit Apply, and it will go out and deploy that in your infrastructure. It's pretty slick and easy to do. So the NetApp driver is fully supported there. We have the controller. On the controller side, we have the Manila service, which is set up in an active pass of HA mode within our high availability on the control plane. We have also the ability to drop in a custom driver if you wanted to take advantage of the LVM driver or play around with some of the other drivers you could. That capability is all available there within our UI in Crowbar. I'm going to walk you through a video that's going to demonstrate the deployment framework and then move into how we're creating a share type and a share within the Verizon interface. I went ahead of myself. Let's go ahead and play this, and I'll just walk you through this video. It started out there on the dashboard, and we can take a look at also the clusters there. This is the BarClap interface that shows all the OpenStack deployment that's available there. We're creating a Manila BarClamp, and we're creating a new back end for Manila. We're creating the NetApp back end for Manila. This NetApp back end, we'll go ahead and put in a few parameters. We'll give it a name for the v-server and the host name and a few other parameters that we can define, the username and the password when we connect up, and we'll go ahead and add that in there. It takes a minute. And then you can use your transport type, whether it's HTTPS or not. And we've gone back up to the top. We deleted the default driver that gets created in there. We didn't want that driver. We can go in and we can add another driver. We can copy and paste this other... the namespace for that driver that we want to add in there. And then we can add in some key value pairs in that field to create another driver. So you can run multiple drivers together using Manila. And then we want to go down to the bottom. We want to remove all the systems out there. We want to make it highly available, so we add in a cluster to the Manila service and then add in our Manila share servers and then click apply. And that will start deploying it into the environment. That will take several minutes and then it will complete. I'm not going to let it wait. And then right now we're going to go to Horizon. We're going to select our share manager. Under the share manager, we need to create a share type. This share type will be used to connect up to the cluster data on tap. We've created our share type and now we're going to create a share off of that share type. We'll give it a name and a couple of parameters. You can select NFS. You can select SIFs. We'll put in our share type that we just created and then click apply. And he will create our share. Simple as that. Not super complex. When you see it in a quick two and a half minute video, it takes a little bit longer than that, but it's not super complex. Let's move on now to what's kind of coming in Newton and what you can kind of expect to see coming here in the future as we move to the next cycle. So share replication, for instance. We're going to expand share replication to cover more cases around things like share servers, especially around some of the other drivers. To make that a little more solid. And then of course share migration. That could use a little work on some of the features. So still not quite completed there on the share migration and that's really in conjunction with some of the other, like the generic driver and other drivers that are connecting into it there. Generic grouping is another feature that we're working on for Newton release. This will replace consistency groups. So there's the idea in Manila with several different types of groups in Manila. So we want to kind of, you know, put those together into its own generic grouping so that they're compatible and that we have one solid stack for grouping within the Newton release. And then of course enhancing interaction between all the other new features. There may be some changes in some of the architectural direction when it comes to the first party drivers. That's being discussed, right? Something that I talked about earlier was the LXC driver and how that kind of died in the Metaka release. Well, that's being enhanced. They're taking that code. I'm not going to drop the code. I'm going to put a little bit more. And now let's put in Docker containers into that and take advantage of using Docker and let's create the container driver. Some other new things are, instead of having an active passive setup for high availability for the Manila service on the control plane, we're going to put that into an active-active high availability service. So you'll see that coming in Newton. And then of course another focus here for Newton will be upgrades. Being able to upgrade the environment. How do we do that? How do we go about doing upgrades on our share servers, right? That kind of thing. So getting involved with Manila, I've got a bunch of links here on some of the resources that you can go back and take a look at to help you get started into the Manila project. Of course, there's always people that are available to help out on IRC. They're very responsive. There's usually 80 or so people always available there on the IRC channel except around this time during summit time. But there are weekly meetings. You can join those meetings. Sometimes they're really quick. Sometimes they'll go on for an hour depending on what the topic of conversation is. Or how many people have really joined that meeting. There are several Manila related sessions. Now this is quite interesting. This really shows the interest in the community today because there are so many sessions popping up now with Manila. The last OpenStack summit there was only three and now we've got literally double or triple of what we had last time. So there's a lot of new things coming along that people are really interested in. And people are starting to use this now, which is really exciting. And then there's also a Manila work session going on right now. And there will be several other time slots throughout the week that you can join if you're a developer if you want to get involved there. And so some questions and answers. If anybody's got questions about the drivers or some integrations with Manila, Susa Distribution. Hi, Gregorit Kretzky from Infinidat. We are a storage provider and we have a NAS solution now. So we are starting to work on the Manila implementation for our NAS. Now the question is if there is any defined certification process for Manila as it exists for Cinder. As far as I know there's no defined certification process that's available at this time. And that may, that very well may come from a distribution I don't know at this point. So what should we do? So it would be great to talk with Susa about that. I know that, see we're working directly with NetApp. We've integrated the NetApp driver specifically. And so that may be something that you talked to us about and we could probably work with you as well on that. Good question. Can you specify the mount points for the share? Or like, for example when you set up the share you'll have an export and a location. But it would be nice for the clients not to have to know. Or is it like the client, the VM's service owner's responsibility who spends up a VM that they have to know. They have to check and rise and figure out the export and the mount location. So the auto mount functionality, that is something that's been desired. That is not something that's been completed yet. Unfortunately, yeah. That is absolutely something that is being worked on. Yeah, no, that's not there yet. No other questions? Thanks for coming.