 Hey, everyone. How is everyone today? Awesome. Great. This session is Manila, Experience It Through Demos. And my name is Akshay Parthasarathy. I'm a technical marketing engineer at NetApp. I work with all things cloud computing, specifically OpenStack. And we're excited to be presenting to you today about the file share service within OpenStack. I'm here today with Dustin Shaneburn. And Dustin, would you like to say a few words about yourself? I'd love to. So hello, everyone. My name is Dustin Shaneburn. And I'm a quality engineer at Red Hat. I've been working at Red Hat for a year. I've been working on OpenStack for two. I've been focusing mainly on Cinder, but now my world revolves around Manila. Great. Awesome. Awesome. So let's get down to the agenda. So this session is primarily going to be driven by demos. And what we have today for you is a series of four demos. The first one you're going to see is the magic of Manila Manage. So with Cinder, Manila, Nova, you're used to creating like a new Cinder volume or new Manila share, or you're used to doing Nova Boot to boot a new instance. Now with Manila Manage, what you're doing is you're importing a pre-existing file share, be it CIFS or NFS, into Manila. And the advantage of doing that is going to become apparent. The next thing we're going to do is to show you the state of the art in the Mitaka release called Share Replication. With Share Replication, we are going to give you the ability to have a second copy or a third copy of your share in another storage controller or in another availability zone should there be a disaster. Beyond that, we have storage efficiency that you can see with snapshots and clones from snapshots. So in this particular case, we are going to use a NetApp Storage back end called cluster data on top. And finally, Dustin's going to walk you through a demonstration of Red Hat OpenStack platform and Manila. So the first thing we have for you is Manila Manage. And I'm going to show you this demo using a particular application. In this case, it's going to be WordPress. And we have a simple blog with some videos and some images. So why would you want to use Manila Manage, be it in this particular WordPress environment or in another application context? Let's say you're a hosting provider. You have not one website as I'm going to show. You have thousands of websites, each with their own images, their own videos. Then having the convenience of Manila in such an environment will become apparent. You could also be an enterprise IT organization that has departmental shares. You could have shares for your marketing, shares for your engineering, be it whatever they may be. You could have user home directories that you have to create. And that cell service provisioning that Manila gives you is going to also be useful with something like Manila Manage. The last use case is maybe you have SAP HANA. And one of my colleagues from that app couple is going to show you a demo of that during another session we have later today at 550 about backups. So he's going to show you SAP and Manila. But for this use case, that is another application. You can use enterprise applications that do need that file share type of infrastructure. You can use Manila for that. So the demo is going to take you through share management, share creation, share extend and shrink. And then it's going to take you through snapshots and replication. Let's get down to the demo. So this is a video demo. And as I mentioned here, we're going to use WordPress, which is basically a simple application to create websites and blogs. So we're starting off here. And we're accessing our web page. It's got an image. It's got some videos. And we click on the video. We see that it has some audio on it. So it looks like everything's working fine. Let's try to now bring this share under Manila management. So we're accessing the WordPress instance, which is actually on OpenStack. And as we should expect, we have a web server and a MySQL database on it. We're looking and we see, OK, there's another share that this WordPress machine is using. And that is the share in which all the images are contained, images and videos. Here's our Nova instance that is being used for WordPress. And here are the different Manila services that we have on our OpenStack machine. Now, we do need something called the Manila pool in order to use the Manila manage command. And that's what I've done over there. So I get the pool ID. I copy and paste that in. And then I also have to copy and paste the export location of that share that WordPress is using. So I'm switching over tabs to WordPress. And I'm copying and pasting that location over here. So at this point in time, we have executed the Manila manage command. And it looks like the share is already available. So we have a share now under Manila management. You do notice that the export location of the share is now a long string in true cloud fashion, where you'll have thousands of tenants. And what has happened, unfortunately, as a result of that, is the video is no longer available. Now, I'm going to get to how you can minimize this downtime. First, we have to set an access policy to allow access. So obviously, in a cloud environment and in general IT infrastructure, security is important. And in the case of Manila, you set security through the use of access rules. So we are explicitly allowing access to your WordPress instance. And we're just confirming that that security rule is added. And we also get the export location that we can then use in our Nova WordPress instance. Awesome. So now we are on the WordPress instance. We've just switched tabs. And we're going to put in the new export location. OK, so those are the two changes that we need to make. And this can all be automated. So these changes will be automated. And I'll provide a script on GitHub that will do it for you. Let's now go back to our WordPress instance, to our WordPress website, and see if we are back in business. So let's click on a video. Looks like the video does play. And we've got our image back up as well. So the next exercise we're going to do is to create a new post on this blog. So updates from Austin. And I'm going to add a image from my local computer. And wait, when I try to add this image, it tells me that it's not able to do it. The reason is the share is completely full, 100% utilized. So what we're doing at this point in time is we're going to show you how you can quickly increase the size of the share. So we have a one gigabyte share. We're increasing it to 100. And you'll see how quickly you can do this. So it's probably been a second. It's set to 100. If you do want to shrink it, we allow that option. And that's what I'm demonstrating over here. We're shrinking it back to 50. And at this point in time, you should have a share that has gone back from 100 to 50. So you went from one gigabyte to 100 back to 50 in a couple of seconds. Let's get back to our original mission of uploading that image. And I'm posting that right now. Looks like the post is fine. And we're going to our website. OK, it looks like we got our new post with our image up. OK, great. We're now going to take a look at a couple of other features of Manila called snapshots and replication. A snapshot is a point in time copy on the storage controller of your Manila share. So we're doing a Manila list command to list your Manila shares. We have that NFS share that is 50 gigabytes. We don't have any snapshots of it. So we're taking a snapshot. And these snapshots are very efficient. They don't consume much space on a NetApp storage backend. Now, we have created a snapshot. But obviously, you want to be able to create. You want to be able to revert to that snapshot when there is a need. So what I'm showing over here is the ability to create a Manila share from that particular snapshot. So that's our share we created from a snapshot. And it looks like it's created almost immediately. And we're now ready to see the final feature, which is share replication. Manila share replication, I'll talk more about this in the next demo. It's basically a second copy of your share that you can use in the event of a disaster if that is the way you choose to do it. So we're using the share replica create command. And then now we're using the share replica list command. And we're waiting for the second replica to become in sync with the actor replica. So we've gone through a number of features. The first thing we did was we had an existing share. We brought it into management through Manila Manage. We then extended and shrunk the share. After that, we took snapshots. And we did replication. So we've done all this in a few minutes. Now, there was that when you did manage the Manila share. In the cloud scale, we are used to using UUIDs and long strings. So what happens when you manage a Manila share is that you get a long share ID, similar to what you see over here. In order to make use of this, what I've done with minimal downtime, what I've done is I've created a script. It's available on GitHub. And it requires a few arguments. But you can basically have your NFS client access policy and your NFS client's FS tab, like basically the mount point updated so that maybe you can reduce this to less than a second or two. That's the GitHub repo. So the next one I want to talk about is share replication. Share replication is the hardest feature in the FileShare service today released in the Mitaka release. And it allows you to replicate from one storage controller to another or one availability zone to another. Why do you want to use share replication? Maybe you want to have non-destructive operations. Maybe you have a single availability zone and you have two controllers. And if your first controller goes down, you want to have a second storage controller takeover operations. So that's one use case. The second is maybe you want to have disaster recovery. Have a second availability zone to which you can fail your shares over and minimize downtime. The share replica create command basically allows you to create a share replica. And you have what I'm going to show you is what happens behind the scenes when you issue that share replica create command. We have two availability zones sharing a common keystone infrastructure. The Manila service has the API. Manila has the API scheduler and share services. The administrator issues a share replica create command received by the API service that is active. The API service looks for a share back end that can fulfill that replica request. It finds a share back end that can do that, which is in the second availability zone. The share back end then contacts the storage controller to make a replica. In the case of NetApp, this is done using SnapMirror. So a SnapMirror is executed from the first availability zone to the second availability zone. And once the replication is complete, the share service updates your MySQL database in your open stack infrastructure to be a replica status available. Let me then walk you through a demo. This demo is going to be done through the CLI, but share replication. We have two availability zones, AZ1 and AZ2. There are no Manila shares, and as a result of that, there will be no Manila share replicas as well. So in order to use replication, you need to set an extra spec called replication underscore type. And that's what I'm showing over here, replication underscore type. We create a new Manila share. We list the share replicas. And we see that it has a single replica in the first availability zone. Let's now go to the storage controller. In this case, it's a NetApp storage controller. And let's see where, if the share was indeed created in the correct backend. So we're just matching the share IDs over here. And it looks like, yes, it's created over here. Now we switch over back to open stack. And we're going to create a replica, which is a second copy of the same share. The first thing we do is we allow access. We're putting a few contents into the share. We're putting a couple of files. In order to put a couple of files on the share, we need to mount the share. So mounted using NFS. We see that the share is mounted. That's our first file. And then we add a second file after this. So if share replication were to be working correctly, you're supposed to see the same two files in the replica as well. So let's now create the share replica. Share replica create, the command we talked about previously. Create the replica in the second availability zone. And now we do a share replica list. And what we'll notice is that, initially, the share replica is going to be out of sync. And after some time, the replica is going to be in sync with the primary. We're waiting for it to become in sync. Looks like we're good to go. We're switching to the storage controller again, just to confirm that the share and the share replica exist in the correct. In this case, it's called a storage virtual machine. And that our terminology. So they exist in the correct storage virtual machine. So we saw the first one. We confirmed the ID. And then now we go to the second storage virtual machine. And we confirmed that ID as well. So if this were to be working correctly, I mean, you're supposed to see those two files on the replica. So we are promoting the replica. We're going to mount the replica. And then we're just going to observe, yes, those two files are available. So that's been our replication change once we promote the replica. We're going to wait until the previously active replica goes out of sync and then in sync. So now we have promoted the replica to the new active. We mount the replica, and we confirm the contents. So directly listing, we see that both the files are there. And we have what we should expect. So what we have seen is Manila share replication that protects you in the event that you want protection against disasters or if you want non-disruptive operations. The next demo we're going to show you is storage efficiency through snapshots. This exercise is going to be done using the Manila UI plugin. So some of you all may already be familiar with Horizon, which is the UI. And Manila has a plugin for Horizon. So that's a screenshot of how Manila UI plugin works. Using the Manila UI plugin, you can create snapshots and you can create clones of snapshots. And by doing that, what you do is you get significant storage efficiency in the case of NetApp. So we're going to create a new share with a large amount of data. And we're going to see that it consumes nearly zero space. So this is the demo. And this is going to be done using the Manila UI plugin. So this is Horizon. We're logging in. You've got the Manila UI plugin enabled. Go to the Shares tab, which is enabled by the plugin. We see that it's got one share. What we want to do is we want to create a new share type that's going to allow thin provisioning. So this is a feature that some enterprise storage backends offer. So we create a share type with the name ontap underscore then with the correct extra spec as we call it in Manila. So this is called an extra spec. So once we have that share type created, we can then go ahead and create a Manila share of that particular share type. So we're creating a large share with that particular share type. So notice the size of the share is fairly large and got created quite quickly. So what we need to do with Manila when you create a share, you need to explicitly allow access to the share. This is done for security reasons. So we have two NFS clients. We're going to allow access to the share. Going back to the Shares tab, and we're going to edit the share to allow two access policies for each of the NFS clients. We add the rule for the first client, and we add the rule for the second client. So we've got two rules added. We're confirming that the share does have the rule, and now we're going to switch over to the CLI so that we can get the export location. This export location is what is used to mount a share. As you should expect, the NFS clients do exist when we do a novel list. And when we do a Manila list, we see that large share. We get the export location, and we mount the share on our first NFS client. So at this point in time, the share is mounted. And we're going to place a large amount of data in the share. So at the completion of this operation, we're going to have over 800 gigabytes of data in the share. So it looks like the data is being written to the share right now. Let's switch over. So in shared file systems, you access the share from multiple clients simultaneously. So we're going over to the other client, accessing the share, and placing another file in there. So the share has already been mounted here. We're placing the file there. Looks like that operation was successful. We go back to the first client, and we fast forward till the file creation is complete. So at the end of all this, the addition of two files, we have about 883 gigabytes of data, so 0.88 terabytes of data. The disk that this poll that this one is using is called AGGR1. So this disk poll, AGGR1, on the share back end, has 1.81 terabytes of used space. So if I create a copy of the share, a clone of the share, it's supposed to use another 0.88 terabytes of data. So in order to create a clone of the share, we first create a snapshot, and then we create a new share using that snapshot. So we're creating that snapshot here, using the Manila UI plugin. And now we're going to use that snapshot to create a new share. The snapshot is available. There's our share. And we're going to provide the share source to be that particular snapshot. So remember, we had 0.88 terabytes of data in that particular share. So if we go back to our storage back end, we're supposed to see that 1.81 terabytes go up by another 0.88 terabytes. So what I'm going to do, we are expecting that to go up to about 2.69 terabytes. But what really happens is that we've gone up only by 0.01 terabytes. So this is a significant storage efficiency that you can see with Manila. And in this case, I have used the NetApp storage back end that gives you that. Manila also gives you the ability to delete your snapshots if you would like to do that. If you do do that, then you get a full copy of your share. It's going to consume that additional space savings that you were seeing. So what you have just seen is storage efficiency with Manila using the Manila UI plug-in. In this case, we were using the NetApp storage back end. So those are the three demos I have to show you. Now I'm going to pass it over to Dustin for Red Hat OpenStack Platform and Manila. Thank you, Akshay. All right. Let me just full screen that as soon as I realize where it ran off to. Yeah, there we go. All right, so hello, everyone. Again, I'm going to talk to you a little bit about Red Hat OpenStack Platform and Manila. You'll have to forgive me if I seem a little bit nervous up here, because usually when I'm in front of this many people, I usually have a bass guitar around my neck. So let's get started. So I'm going to give you a brief overview of what's going on with Manila and Red Hat OpenStack Platform. So currently, NetApp cluster data on tap Manila driver is the only supported driver currently. So we are the only OpenStack distribution at the moment to support Pacemaker HA for Manila services right now in active passive for all. It is in tech preview. We support it on a best case basis. We're hoping to have full support by the end of the year. And you can install Manila into an already deployed Red Hat OpenStack Platform Cloud today. So I'm going to chat a little bit now about how we install, manage, and configure an OpenStack Cloud. And for those of you that are more familiar with Red Hat's Cloud offerings in the past, we've had different ways of installing it through, say, PacStack or StayPuffed. So Director is our next generation. We decided that instead of building things in-house, we would leverage what the community already gives us through such services as Triple O and Heat. And so what this does is it constructs an undercloud that we use to then the workload for that undercloud is your overcloud. So the thing that actually is the OpenStack Cloud that you will be using. So I'm going to show you a little diagram here of what that all looks like. So you can see here that we have all of these services in the undercloud here, such as Fuel, Keystone, Horizon, all of these services here. And all of these work together to run, update, and monitor the overcloud here. And you can see that there is some overlap between services here and services here where they are replicated. They're separate. They just do the same thing for each individual cloud. So the bad news for all of this is that Manila can't be installed by this director yet. But the good news is that one of my colleagues at NetApp, Dave Cain, has written scripts that will help you install. And Dave, you were in the house to holler, wave your hands. He might be out doing something else. So I'm going to talk a little bit about these here. It's a set of four scripts that consists of start, all systems, controllers, and controller 0. So the start script is where everything begins. It is the thing that copies all the other scripts to the requisite nodes in your overcloud. And then all systems is configuration for all systems in your overstack. So this will install the Manila packages so that they can all interact with Manila. The controllers is for your controller nodes within your overcloud. So this will generate your Manila configuration file for all controller nodes. And then the controller 0 script, what it does is you only need to run this on one controller node. It defaults to node 0. You can set it to whatever you wish. And it will create the Manila role and user, as well as the Keystone service entities. It will create the Manila database, configure the API endpoints for Manila, and it will also configure pacemaker HA. So if anyone wants more information on this, you can talk to Dave Cain or check out the source on GitHub. I have a link in a future slide in the deck. And to run it, you just simply do dot slash, flexplotupdate, start.sh. Couldn't be easier. You will need to have your StackRC source. So now it's time for the fun part. Let's get into the demo video here. So I'm going to show you the configuration file that is generated by the Manila setup scripts. I'm going to show you the NetApp Storage Controller configuration through on-command system manager. And I'm going to watch a share be created and show that things are actually happening on the NetApp back end. So I'm going to pull that up. So here we can see the default configuration section of your Manila comp. So these are things that are applicable to all of Manila. So you can see here log levels, where the logs are, as well as how to interact with other OpenStack services, such as Nova, Cinder, and Neutron. So those all go into your default stanza. And then once we go to the end of the file, we will see sort of the more specific configuration options. So this will show how to interact with the messaging queue, concurrency, your database connection, Keystone authentication, and then finally, the actual configuration for your share driver, which in my case was a NetApp back end. So this is all configurations as specific to a NetApp back end. And so I'm going to switch over to this other tab here and show you how to create a Manila share through the CLI. And I make note that we are using a pre-created share type here that just specifies to use the NetApp back end for share creation. So it spits out a bunch of information about the IDs, snapshot support, and all this stuff. And I'm waiting a little bit here so that we can show the share status as available. And then we can use that information to get the share ID, the export location, and any other details that we may need. And you do that through the Manila show command. Yeah, so you can see our status is available. We have our export location. You would use this in your Nova instances to mount the share that we just created. And you can see here the same thing that Akshay did through Horizon we're doing through the command line by allowing access to the share that we created. So now over in on command system manager, we're showing our demo cluster with our Manila storage virtual machine. You can see the share here that we created. It's online. It's one gig in size. Now you may notice here I sort of draw underneath that that if you're watching closely, you may notice that that ID is different. It's because it's using the share instance ID instead of the share ID. And you can see here the export policy that we created. It has the correct IP and the correct permissions. Thank you, VLC. So for those of you who are curious about the source of the scripts here, the GitHub link is right here. You can check it out, run it, see how it all works. If you want to learn more about what RedHack is doing with OpenStack platform, you can check out the landing page here. For more information, I'll just have it. So what do we learn today? So actually, I was showing you, showing everyone, share management and features are very powerful in Manila, as well as making use of replication, snapshots, and consistency groups for enterprise applications. You saw the WordPress thing. You saw the mentionings of SAP HANA. And I talked to you. Share replication. Yeah, share replication. And I talked you through a little bit of what we at RedHack do with our own OpenStack distribution and how to do things in Manila with it. How did it do that again? So that's all we have today. If you're curious about any other things that we have going on today from the RedHack side, these are the sessions that we have going up. Feel free to take a picture. Make sure if you want to see a little bit more about what's coming in the future of RedHack OpenStack platform to check out the RDO community meetup. It's our upstream for RedHack OpenStack platform. So be sure to check them out. And Akshay, I'm going to pass it back to you to talk about what sessions NetApp has coming up. Thanks. So here are the NetApp sessions. These are arranged chronologically. Obviously, there are some that have already been completed. Please be sure to check them out on YouTube. If you want to take a picture, now would be a good time. Got some more sessions over here on Wednesday and Thursday. So on behalf of NetApp, I want to say thank you for staying with us in this session. If you would like to meet with us and talk with some of our leaders, please schedule a one-on-one VIP meeting. Follow us on Twitter and visit us on the web at netapp.github.io. And on behalf of RedHack, I want to thank everyone for showing up. And if you want to see more of what we're doing in all things open source, we are on every social network. So feel free to follow us. Could you use the mic? Could you use the mic? Thank you. Thank you. I think we have time for a couple of short questions, maybe. Now, come up and see us if you have questions. OK. So a replication on the replication side. You showed this application working with a snap mirror. Yeah. Is it possible to use vendor agnostics replication plugins? And is it possible to define custom plugins? So right now, we're actively looking for other vendors to be part of Manila and use share replication. So we're actively looking. But if you use netapp, then you can use replication. Do we have any others that are using ZFS? ZFS.