 All right. Well, thanks for everybody for hanging on. And we were just laughing. It's funny at a technology conference. Of course, there's technology issues. And it's the most simplest thing, trying to get the video cable working. As I'm sure we're all aware. But again, thanks again for talking. I'm Brian Elson with IBM. And we recently worked on a project to help migrate from one cloud to another. The work that a lot of times we do is bringing data on-premises. So we're really concerned with on-prem cloud. And so in terms of having customers or whoever, often there's data that's in different clouds. And you want to move it from one cloud to another. There's a lot of different reasons for that, as you can imagine. You have your data in the public cloud. And you want to enjoy the experience of doing an on-prem cloud. Maybe you have an on-prem cloud, and you want to experience the joy of doing public cloud. Or you just have two clouds and two storage places, and the data needs to be moved from one to the other. And when you're thinking about it, obviously there's a number of concerns that you have to do. Primarily that the storage layout is usually quite different. You can't just essentially take this data and pop it down and suddenly have it start working. It has to be a migration. You may also have files that you want to start getting into the objects. There's also quite often metadata associated with the objects that need to get migrated. You have ACLs, different kinds of permissions. And different vendors who offer cloud storage may also have additional value add that they have on their object storage. And so there's concerns about when you migrate to a different storage system. And so when you're thinking about it, you want to try and estimate, well, how long is this going to take? How much disruption is this going to be to my clients and my customer? Can I accept downtime? And if you can't accept downtime, then you want to look into more of a online migration where you have the systems up and running and clients can access them while you're doing the migration. You have existing clients who are talking to your old system and you've got to start getting them rolled over to start talking to your new system. And then while you're doing all this, you're reading and writing a lot of stuff flowing across the network. There's going to be performance issues with that. And then when you're done, when can you say, OK, this done with this old storage. I can stop paying for it. I can throw away the hardware or completely reuse it. So obviously there's a number of solutions today. You can actually carry the data from one site to another when the systems are the same. Just however that happens, disks, tape, whatever. A number of third party vendors are also involved in this space. And so depending on the solutions that that vendor offers, that can also work. Typically that costs money. Quite often we end up just writing tools ourselves to go ahead and do the migration. And there's nothing that kind of works for all solutions. It's you're definitely going to have to take a look at the situation to see what will work in your environment. So what we were doing, as I said, we have customers who are trying to move from the public cloud to more private clouds. And so they just were kind of interested in a way to do that. And so what we do is we have this object migration tool. And so right now we support the Amazon S3 Swift cloud, and as well as just files on the file system. And then the object migration tool will be able to migrate all those into a Swift object storage solution. And this makes use of the migration middle tool that's part of Swift in the part of Swift community, as you can see right here. And the way that this works, it's a bit of middleware that takes a look at the request. So when you do a get to Swift for your object, you do an initial get. The request flows through normally. In this case, the object's not there. So the middleware notices, hey, there's a 404. And so what it then does is it'll take a look at the container that the object is coming from. And it looks at the metadata on the container to see if there's a little bit of migration information that's there that's linking it to an external cloud. And if so, what the middleware does is it goes ahead and does a get and then sends it on into the Swift object store. And so then that object then becomes an object. So the middleware kind of becomes a client in this space. But the actual customer, external client, doesn't really know this is happening. They just do a get. If the object's local, then it'll pull it from there. And if it's not there locally, it'll get it from the remote one. And it'll also make a copy in the local storage. So the next time, it'll get it from local. And a little bit more detail on how the migration, that migration middleware works. So it's going to read the configuration information from the migration file, which has some information. We'll get into that a little bit later. And so what that tool does is when you start it up, you have to initially configure it with who the cloud provider is that you're going to be pulling the objects from. And then based on that provider, it will get the list of it'll list out the container to get the information of the container and the metadata. It then creates that container in the Swift storage and applies the metadata on that container so that the middleware will have access to it. And then it will list all the objects in the source container. And then for all of those objects, it will then do a get in your Swift to trigger the middleware to do the pull of the objects. And in this way, it can completely migrate a whole container into your new Swift. And while this is happening, your old clients can still be talking to your old data storage as well as to your new one. Your clients can be pointing to the new storage because if there are any objects that aren't there, they'll get pulled from the old storage. So we have a few enhancements though we did into the middleware. So for the S3 ACLs, I mean for the S3 ACL support, yeah, we added some more into the live cloud there. We also did work for the large objects. And so the migration can now split up the large objects into segments. And then we have also support for the Keystone V2 and V3 authentication. And so the tool is pretty simple here. We just, there's a tar and just with these tools in it. And when you run the setup, it'll put the files in the right places in Swift. The proxy server needs a modification to have the data migration middleware, as we showed in the example. That's the middleware that's going to trigger this action. And there's also some information in the data migration section that has information about the system that you're pulling from. And so here's just some quick examples of I was doing S3 migration. In our tools migration file, you have to say what the S3 information is, which is these variables. And then just we would run the migration script. And in S3, obviously I have to do the first section is the S3 modification I have to do in the proxy server to enable the proxy server to be able to understand S3 communication. And then also in the proxy server, have information about the source cluster so that the middleware can pull that. And the bottom is how we generate the S3 secret using that credential create. And if we were doing Swift, obviously, you're probably these variables all over very familiar, but this is saying, OK, if I'm going from one Swift stores to my Swift storage, then I just got to have that information so the middleware can make use of that. We also have file, file to object. And so in this case, this is a local directory. And so I'm saying, OK, this is how I would transfer slash ETC all the objects underneath it. The objects will be stored as the container will be ETC. And all the files under ETC will be objects in the ETC container in this case. So in this kind of solution, it would be good if you're going from S3 Swift or a file system and you're going into another Swift. It'd be very easy to add from other cloud systems as Azure or Atomos and stuff. And also, we pull some of the metadata in Swift and S3, obviously. But of course, there are limitations in everything. When we're the data that we attach to the container to do the pull from the source storage, that's on the container. So you will have the authentication information there. That'll be something to be concerned about in your environment. The tool only really migrates the Swift attributes, the object data, the user metadata, and then the ACLs. And if you're in an object storage that has other vendor-specific attributes, then you'll need some other way to migrate those. And right now, it's just migrating the one container in that user account that you specified. So the tool right now doesn't allow you to, say, migrate everything in this object storage. It's really just on a user basis. So and this would be if you want to make a new driver to Azure or whatever. This is kind of the steps we would take. Just a lot of the frameworks there is just a matter of hooking it into the live cloud so that it can pull the information and then saving the configuration variables. So we do have a quick demo, which is really just what I was talking about. But based on time, I think I'm going to switch, skip the demo. Sorry about that. But it was basically, so the demo was going to show the untarring it. But let me go ahead and skip that. So it showed the untarring it and running it and pulling it from Swift. I know we're all hungry. So like I said, this tool, we primarily did it because we had customers who wanted to migrate their data into the spectrum scale in the on-premise cloud. But it can be used by anyone, obviously. We're still doing a little bit of work on it, but check on developer works for its availability. And like I said, this is part of spectrum scale, which is our clustered parallel file system facility. And I think that's it. All right, well, thank you very much. Any questions? All right. Enjoy your lunch. Thank you for sticking around.