 Hi, everyone. Let's get started. So welcome to SnapThis, making Snapshots vastly more useful in Manila and Cinder. So my name is Clinton Knight. I'm a senior software engineer at NetApp. I've been in storage management applications development for about 18 years, the last three of those having a great time in the OpenStack phenomenon. I'm a core developer in the Manila project, and most recently I led the development of the revert to Snapshot feature in Manila. Hello, everybody. I'm Rodrigo Barbieri. I'm a computer scientist. I've been in software development for six years so far. Three of those years I've been in OpenStack, mostly in Manila, where I'm a core developer. And I've worked in several core features, notably share migration and co-altered mountable snapshots, which we will discuss in this presentation. So first, we will start by explaining what a snapshot is. Then we will list the use cases for which snapshots are useful in a cloud environment. Then we will get in detail about all the different semantics that exist in Manila and Cinder. And we will demonstrate those. And finally, we will get question and answers. All right, so there's a lot of storage systems out there. And we find a fair number of implementations of what passes as snapshots, not all of them consistent with what we would expect a snapshot user experience to be in OpenStack or in any cloud. So I wanted a level set about what we expect a snapshot is. So a snapshot, it's an image of a cloud storage resource. Could be a Cinder volume. Could be a Manila file share. But that snapshot is typically going to be local. That means it's really resident on the same underlying hardware that's satisfying the storage resource. Anything else that's not local wouldn't give us the performance characteristics that we're looking for with snapshots. We've also seen storage systems where snapshots are actually created as an interdependent chain of snapshots. And you really can't delete a snapshot in the middle of the chain because they can depend on one another. In OpenStack, the expectation is that the tenant can create, utilize, or delete any snapshot at any time. That's the contract. They're the both Cinder and Manila promise. Similarly, a snapshot is a point in time image of what that resource contained. So any mechanism that, for example, copies files out of an active file system and calls the results a snapshot really isn't, because it wouldn't reflect a single point in time. And then finally, a snapshot is a read-only resource. At the point it's taken and then forever after that, it should always contain the same thing. There's several other reasonable expectations that you might have for a snapshot in a cloud. The first is speed. So by that, I mean a couple of things. One, the underlying storage resource should not significantly slow down in the presence of one or more snapshots. So some storage systems implement a copy-on-write or similar mechanism. So you might see a little bit of degradation in write performance if there's snapshots present. But there are storage systems out there that offer zero performance penalty in the presence of any number of snapshots. Also, creating and utilizing and deleting the snapshots, those operations should themselves be fast. Really shouldn't take any time. We're not talking about creating full copies. Snapshots should be space-efficient, okay? So taking a snapshot shouldn't consume additional space on the storage underneath that, at least not at the time that you create the snapshot. Once you have a snapshot and then writes continue to happen in the underlying storage resource, of course you're gonna begin consuming more space. But at the time you take a snapshot, you shouldn't consume really any more space. And then finally, as a cloud tenant, you should be able to control the life cycle of the snapshot yourself. Should not require any admin or pension. So if your cloud doesn't offer snapshots or if the snapshots don't conform to these expectations, then you're probably not being served as well as you might be by your cloud and it's underlying storage. Finally, a snapshot is not the same thing as a backup, we should not conflate the two. So a backup typically implies a full copy, typically held at a different location for greater resiliency. A backup may even be in a different format. For example, Cinder has a backup service that can back up to a Swift interface, storage grid or an NFS share or what have you. But because of these considerations, that the separate location in a different format for storing from a backup typically is gonna take a much longer time. By contrast, snapshots should be very fast if not instantaneous. So when we talk about snapshots, the first use case that pops to mind is recovering lost data. So your data may have been lost due to several reasons. Among them, it may have been deleted accidentally or a virus may have wiped your data or the file system may have become corrupt and the data is no longer accessible or the user maybe had just deleted the data and ended up regretting doing so. So for all those scenarios, having a snapshot allows you to restore your lost data. And as Clinton mentioned, backups are not the same as snapshots. And if your cloud does not offer a backup service, having a snapshot is very useful to restore the data for the scenarios I mentioned and if your snapshot is replicated, it's even better because your data will be will be stored across several availability zones. So some other very interesting use cases, they emerge when we start using snapshots as images. So let's picture for a moment that you have to do a training session and you need to prepare an image for your students to use consisting of pre-installed applications. So what you can do, you can create a volume, install the operating system, install the applications, then you can take a snapshot and from that snapshot, you can spawn several new volumes for your students to use and they can be deleted later while you maintain your snapshot data intact. For big data analytics, you can do basically the same thing. Using pre-existing snapshot image, you can create several new volumes or share for data processing and you can easily dispose of them when you're done and you can do this repeatedly over time for several data mining grounds. For DevOps, there is a very interesting use case. So let's say that you have a new version of your application and when you deploy it, you'll find a critical bug in your application or a software update had just crashed your operating system and the thing you won't do at this moment is to restore, sorry, I mean revert your application or in your system state back to the previous stable state. So snapshots allow you to do that in a matter of seconds. Another very interesting use case is that since snapshots are very efficient, you can save multiple states of your system. So let's say that you're installing libraries and your application in a new operating system that you're not sure it works. What you can do, you can take a snapshot at each step of the installation or each component that you install so you can validate that everything is working and if something does not work, you can just go back to the previous step and redo that. Another one that is very useful when you use snapshots in Manila is that if you're sharing your work across your company, across several other departments to the network, what you can do, you can create snapshots as milestones of your work and you can continue working on your latest work in our original share and just take a new snapshot when you hit a new milestone and you can do that with multiple snapshots. So let's go through the three semantics for snapshot operations. The first is to create a new share or new volume from a snapshot. So the idea here is that given a snapshot, we're gonna create a new independent writable object be it a file share or a volume that's initialized with the contents of the snapshot. So it sounds like it's, well, I could just do a clone but it's not quite the same thing. So in Cinder, you can clone a volume repeatedly but if the parent volume is as undergoing change then each clone is gonna be slightly different. Whereas if you can take a snapshot then you can repeatedly create a new volume from that snapshot, you still get a fully writable independent volume. But each one of those is gonna be identical to the snapshot. So create from snapshot has been available basically from the beginning in both Cinder and Manila. So create from volume can actually satisfy most of the use cases that Rodrigo explained. In some cases it's ideal, some cases maybe not. Certainly with software testing or training with a room full of students and you need lots of copies of the same thing, creating writable objects from a snapshot makes a lot of sense, same with analytics. In the DevOps use case, if I need to roll back to an earlier version of an application that doesn't have a bug, in this case I could do that but I'm gonna have to run my application against a different volume so it's gonna be a little bit more work. If I'm creating a volume or a share from a snapshot it is gonna consume additional space and in some implementations it may duplicate the space upfront and others you're gonna be consuming additional space as rights happen to the underlying volume. But it is gonna also consume additional quota. So to create a new volume or share from a snapshot you've gotta have enough quota for the volume count but as well as the volume space. So Cinder and Manila they don't have any concept of space efficiency on the back end they don't know if you're gonna be consuming space periodically but if you take a snapshot and create something from the snapshot but then the parent completely changes then you've consumed twice as much space anyway. So you're gonna double your quota consumption as you create shares or volumes from snapshots. So semantic number two, this is one of the new ones that's in Manila. So basically reverting a file share or a volume to a snapshot. The idea here is we're gonna do an in place revert or restoration of a share to the contents of the snapshot. The neat thing here is that you can do that repeatedly. So if you're doing some data experimentation you can take a snapshot, do a bunch of writes, revert to the snapshot, write something different and repeat the cycle. So you're literally with this feature turning back the clock to the point in time that the snapshot was taken. So an important consideration though, a limitation here is that there's a number of storage systems in the world where if you revert to a snapshot, any and all snapshots that were taken after that point in time are lost irretrievably. The Manila community felt very strongly that that was a form of data loss and so we designed this feature to only allow you to revert to the most recent snapshot known to Manila. That's actually not terribly limiting. If we talk about the use cases that we were going after in this case. So take the example of widespread data loss or corruption. I've deleted a bunch of files. Maybe I got some malware or I did something stupid. I just wanna turn back the clock but if I revert to the most recent snapshot and the corruption is still present, well that snapshot's not much good to me so I'm gonna delete it and then revert to what's now the newest one. And I can repeat that cycle until I get back to a good state. Same with the DevOps use case. If I need to get my application back to a state before I introduce the bug, I'm gonna delete snapshots one at a time until I get back to a good, good state. All right. So unlike Cinder, which understands that a volume is in use, Manila has no way of knowing that a file share has been mounted or is being used by an application. So stopping or otherwise quiescing the application is a manual process for the application owner to do. Most apps aren't gonna react well for the file system instantaneously changing out from underneath them so the apps should be stopped or quiesced. There may be some data. The application owner may understand that the share contains some data that he wants to preserve that was written after that most recent snapshot was taken. So in that case he might wanna do a manual copy of some data or maybe take another snapshot and create a new share from that just so that he has a copy of that. Because once you do the revert, there's no undo, okay? You can do it repeatedly, but once you do the undo, you're not gonna be able to get to any point in time after that. So revert snapshot was added to Manila in the Ocata release and just last week Cinder merged a spec for the same feature and I know that they're working on it. I think the Cinder community has done a good job of trying to maintain consistency with Manila as to how this feature is gonna work. Okay, let's talk about another snapshot semantic now, multiple snapshots. So with multiple snapshots, our snapshots are basically read-only shares which you can give access to users on your network by adding access rules. So very similar to how you handle shares. Multiple snapshots are very efficient in a way that they're consumed absolutely no extra resources since the snapshot data is already there in your storage controller and what you're doing, you're exporting it to make it accessible directly. So it satisfies the use cases very well where you just want to retrieve a subset of files or folders that you may have deleted or lost. And it's not very recommended when you want to restore all your data or operating system data. For those purposes, it's better to make use of the other snapshot semantics Clinton mentioned it. And it also satisfies the use cases where you wanted to share your milestones of your work across the network. It's available in Manila since the Ocata release and we believe it's unlikely to be available in Cinder. So now we're going to proceed to our demonstrations. First, let's start and see how we can enable and make use of those features in Cinder and Manila. So first, let's login as administrator so we can create a volume type. So we go to the volume type screen, hit create volume type and we create a new type. Add a name, hit create and that's it. We create a volume type and we can proceed to create a volume using the type we just created. Now that we created a volume, we can create a snapshot of this volume. We give it a name and hit create snapshot. Now that we create this snapshot, we can create a volume from this snapshot. There we go. We have a new volume from a snapshot. As you can see, that's very simple and straightforward. Now let's see how that is done in Manila. So in Manila, we can proceed to create a share type now in order to create our shares. And when we do so, we give it a name and we have to specify the public as respects. Here I'm going to say that I want snapshot support. We do this because we don't expect all storage vendors that have drivers in Manila to all support snapshots. We'll get more detail in that in a few moments. So we create a share using the type we just created. Now we can create a snapshot of that share. And upon inspecting that snapshot, we see that's just a simple snapshot. It does not have an export location we can mount. If we inspect the share, we see that it was created without mountable snapshot support. The reason for this is that we also have to specify the public as to expect for mountable snapshot support if you want to have this functionality for this set of shares. Again, not all backend support this cement. Some support revert, some other support multiple, some support both. So that's how we use our public as to specs mechanism in Manila. So now that we have created another share type and we specify that we want mountable snapshot support, we use it when creating another share. Now we create a snapshot. And now if we inspect this snapshot, we will see that it has an export location. If we inspect the share that we created, we will see that it has multiple snapshot support because we use a share type that specifies that in the aspects. All right, so I'm gonna re-log in as a regular user, obviously to create types in both center Manila, you've gotta be an admin. So I'm just gonna go and run through the quick semantic creating from a snapshot. So I'll create a share, default type, pick my primary AZ. So this is what a normal tenant would see, create a snapshot. And then starting with the snapshot, I can create a share, just that simple. So of course I can give it a name, a different type. But down at the bottom, the snapshot source is prefilled in as the snapshot that we started with. All right, so now share two contains the contents of the share one snapshot. All right, so now let's move on to revert. So I could just create a share and a snapshot and revert to it, but that would be a little bit anticlimactic. So I wanted to have a little bit of fun and also include one of Manila's other advanced features. So Manila supports tenant-controlled replication of file shares. And so the rule is that Manila, if your driver supports snapshots and it supports replication, then it must also support replicating all of the snapshots of a replicated share to all of its replicas. All right, so we'll see that as part of this. So I'm gonna create a share, pick my replicated type that I set up. And again, I'm gonna choose my primary availability zone. So primary, in my case, this is my data center where I work. And so this share will be created on NetApp's on-tap storage operating system. But this is a replicated share, so I'm gonna go in and say manage replicas because I wanna create a replica. I need this to be highly available. So I'll say create replica. And there's only one choice here. So a little bit more background. I also set up an instance of cloud on tap from NetApp, which is fully virtualized storage operating system running in Amazon, could also run in Azure. So I can choose the availability zone called AWS. And so if you think about, wait a minute, this is pure Manila. And yet somehow I've overlapped OpenStack with Amazon. So I can only afford one data center, but I can have the same storage and replicate out to a completely different cloud. That's a cost-saving measure. But also it opens up some interesting use cases of being able to do migration of applications and their storage between very different clouds. So anyway, enough of that, back to revert. So my replica starts out as out of sync. Within a few seconds, it'll become in sync. And so now I've got the same copies, two replicas of this share at different sites. So now I'm gonna go and create a couple of snapshots. So creating a snapshot of a replicated share takes a little bit longer because Manila has to make sure that snapshot is replicated to multiple locations. Create another snapshot. Creating two so that you can see Manila applying the rules for revert. So I have two replicated snapshots. Go back to the share and I can say revert share. So there's a pop-up here, but Manila has only given me one choice because I know that Snap2 is the most recent one known to Manila. If I wanted to revert to Snap1, I would have to delete Snap2 first. Okay, so the status transitions through reverting back to available and the revert is complete. It should be an instantaneous operation. Let's take another look on how we use multiple snapshots now. So let's create a share. Let's create a share type that supports multiple snapshots. Now let's do a little experiment. Let's mount this share. First, let's add an access rule. So we can mount it in our user terminal. So let's grab the export location. And now we can mount it in our terminal. All right, let's add some content to this share. Let's just create a sample file. All right, we've got our file over there. Now we can take a snapshot of this share. Great, now that we've taken a snapshot, let's add some more content to this file which will not show up in the snapshot. So we have a sample file now with two lines of text. Now we want to mount this snapshot. So let's grab the snapshot export location and try to mount it. But it will not work unless we add an access rule in order to mount this snapshot. This is because the access rules for snapshots are not inherited from the share. So now that we've added an access rule, let's just try to mount it again and we've succeeded. Let's inspect this snapshot. And we see that we have the sample file with just one line of text. And we see that it's also read only as I've explained it. So we cannot change the contents of this snapshot. So at this point, are there any questions? Questions about the snapshot semantics? Arthur, you have a question? You mentioned that you couldn't do this with all of the back-ends out of that and all the storage systems that are part of the monolartry and stuff. So how would I as a user be able to distinguish and get these? I'm a user, I'm looking at an OpenStack Cloud. How can I create a share? And how do I know upfront that I could get these features? That's a great question. So, and that highlights one of the differences between Cinder and Manila. So Cinder has always said that we expect all back-ends to have the same set of features so that if you have a Cinder interface, you know it's gonna be there. With Manila, as we were moving forward and adding drivers, it was clear that there are some cases for a low-end storage tier that you just wanna provide file shares. You don't necessarily need all the advanced features, perhaps not even snapshots. And so there's actually value in having different feature sets. Of course that begs the question, then how do I as a user understand that? And so, just like Cinder has extra specs on volume types which are completely hidden from the user, Manila also has extra specs on the share types which are hidden from the user. But Manila also added, they pierced the abstraction a little bit and added the concept of a public extra spec. So you can think of it as kind of like a tenant-facing capability. So for a given share type, you can look at those public extra specs and understand, if you create a share of this type, what features are going to be available for it? So, and it was important not only for you as a user to look at your screen and understand what you could do, but we also wanted those to be discoverable programmatically. So if you're scripting the Manila interface, you wanna be able to understand what you're gonna get. So that's why we have the public extra specs and a set of community-agreed standard names for those extra specs for the features that may or may not be present on a given type. Thanks for the question. Anything else? All right, thank you all very much. Thank you. Thank you.