 All righty, welcome everybody. So my name is Sriram Kalyan Sundaram. I'm Director of Implementation at Tessora. So we are going to talk today, I just discussed today about the topic is best practices for deploying OpenStack Trow. And we are going to go through that. Wait for the last minute stragglers to get comfortable. All righty. So like I said, I'm Sriram Kalyan Sundaram, Director of Implementation at Tessora. I work with customers as well as people that would like to know more about our product and what Trove does and things like that. Trove has been around for a while and we'll talk about it. When I put to this chapter, so I had offered two courses. One is an advanced course on tuning Trove as well as this one, and luckily I guess this one got accepted. So what I would like to do here is intro to Trove. And as part of this, I would like to provide people that are interested, I have around 20, 25 or so thumb drives that contains a full DevStack plus the latest version of Trove. If you want to try it out on your laptop or something like that, you can definitely do that. I'm happy to provide that to you and a small demo and then take on questions. We have a booth here and we have been talking to a bunch of people and we find that while some of the folks understand Trove very well, there are a lot of people that don't understand D-Bass and what does it do and things like that. Given the fact it is an introductory session, a beginner session, it makes sense to talk about Trove, what does it do, show you what it does before talking about the best practices. So we are going to talk about what is Trove, how does it work, just quickly show you how you can see the action and then go into architecture and then talk about the best practices or what is the best way to deploy it in a POC environment to test out your use cases and scenarios followed by how have some folks deployed that in production. I see I only have 40 minutes for this session, so what I would request is that we will bucket some time for questions and we'll leave it at the end, that way we can cover the materials, have your questions ready and we can go through them at the end. So what is Trove and once again, to make sure everybody's on the same page, right? So Trove is a project like any other project, Cinder Swift, Nova, Glance, Keystone, right? Trove is a project that is designed to provide databases as a service. It came up in Havana, it's 2013, so it's three years ago and then it got integrated in ISOs. So for the last two and a half years or thereabouts, it's been part of OpenStack. Just a quick background, HP and Rackspace started it, but now if you look at the latest comets on Stack Analytics, you will see Tessora, I work with Tessora, we're the largest contributors to the Trove project, but we have Rackspace, HP, IBM, Red Hat and a bunch of folks that are doing it. And by the way, I believe this, there's a video being taken of this and you can get it in a couple of days from the OpenStack website and I'm happy to share. As part of the thumb drive, I will have a PDF of this presentation too in case you're interested. So if you say Trove is databases service, what do you really get with it, right? So for those folks that are familiar with the Amazon RDS, I'm just trying to draw a parallel so it's easier to understand, right? So there is a whole bunch of databases that we can easily provision with Trove. Trove does a complete lifecycle of that. So for example, if you have a bunch of developers in your organization and they're saying, hey, you know what? For my applications, I need databases, but I need to use a variety of databases and I don't know all the databases and how they work. So how do I go about creating and using those databases? And that's where Trove comes in. So using Trove, you can spin up both SQL as well as no SQL databases. So if you talk about it, there's a slide that talks about the databases that are being supported, but you can have MySQL, Oracle, or Postgres. On the same hand, you can have Cassandra, Mongo, Coachbase, and the like. And idea is that it provides the same interface to access all the databases. So you don't need to learn different ways of accessing different databases. If you learn how to use, for example, MySQL, or Postgres, or Mongo, that's the same way you access any other database. That is a cool thing about Trove. And in addition, it provides a complete lifecycle management. What does it mean? It basically means that Trove handles through the command line out of the GUI all the way from creating a single instance or a replicated pair or replicated pairs, if you will, or a cluster, growing a single instance, shrinking a cluster, growing a cluster, backing up, restoring, failover, multi-DC support, monitoring, automated patching. It does all of that. So if you're a developer, if you're a DBA, it makes your life very easy in managing a bunch of databases. Keep them all up to your company's InfoSec standards. If you're a developer, you just want to go through GUI just like you get compute, just like you set up networking. If you just want to set up a bunch of databases, use them, throw them away, take backups, take snapshots, you can do all of that. Like I said, so these are all the databases that are available as of right now. If you look on the column on the left-hand side, these are the community databases, MySQL, the different flavors of it, Percona, MariaDB, Mongo, Cassandra, Couch, Redis, and then on the right-hand side are the commercial databases. So given the fact they have license behind them, they are not available as part of the community, OpenStack Show. I cannot talk about the complete lifecycle management. I cannot touch upon a little bit just to kind of go over that. When you create a database, it's not enough that you create scale up and scale down. There's a whole bunch of things that goes with how do you use a database, especially when you talk about using a database in a QA or in a production environment, right? So you want to be able to create databases single instance or clusters. And once you do that, obviously when you, I have talked to a number of people and they say, hey, you know what? I have a Chef script or a Puppet script. How is it so different from that? I mean, I can approach in a database, sure you can. I think the thing to keep in mind is that not only do you want to create databases, but if you want to say things like, if you want to manage them, then once you create a database, you have the database instance, the database server if you will, right? You want to be able to create within that instance the server, a variety of databases, variety of users, schemas, and then once you do that, you want to be able to take backups, restore that backup, take schema snapshot and all of that, right? So that is part of carrying and feeding of the database, right? So you can do that once again, using a command line or using a graphical interface, you can do that with Tro. And then once you have a database up and running, especially in a production setting, you want to be able to tune, right? So Tro provides databases with a standard set of parameters that you can use, but every company that I work with, I know that they have their own standards for maintaining those databases. So how do you do that? So Tro provides you all the default parameters for every database. You can further act to them or refine them if you want to, that's number one. Number two is that you can say, I want to take a small set of those parameters and I want to tune them. So you can use Tro to do that. And also, you know, you have APS for custom configurations, right? That's pretty powerful. And if you are talking about monitoring everybody that I talk to these days, say that, hey, you know what, it's great to have a database, it's great to have them up and running to scale up, scale down. How do I monitor that? And when you talk about, okay, we support monitoring, then the question comes is, company A says I have monitoring tool A, company B says I'm monitoring tool B, and so on and so forth. So what Tro has done, the community is, there's a feature called module management. And using that, you can use any monitoring tool that you want and you can deploy that as part of Tro. So you don't have to be forced to do anything that you want. As long as you have a plugin for the monitoring tool, there you go. You can use Tro when you can collect the data and you can do whatever you want to do with it. And from a security perspective, Tro doesn't let you, Tro lets you access a database instance only through the public interface, which basically means that you can't, if it's a MySQL, you can use it using the MySQL interface and if it's Mongo or Cassandroid through that, you can't really SSH into the instance. It makes it very, very secure. And another part of security is that, when we talk to customers, the question is whichever way you create your images, we provide images as part of Tesora, but if you choose to use the community Tro, we are part of the community here, you can create your own guest images. And if that is the case, how do you make sure if the Linux vendor has a patch or if the database vendor has a patch, how do you make sure that you keep your instances running up to date with all those patches, right? So there is a functionality where you can update one instances or you can create a simple script that you can update all running instances of a particular database type with the latest patch version. So that is pretty powerful. So not only can you create databases, create clusters, grossing them, that's standard stuff, but you can cat and feed it back up. You can tune, you can secure, and you can monitor, and you can make sure it stays up to date. Some basic terminology as we kind of go through the architecture and things like that. So most people here, or if not, everyone is familiar with the concept of an image, right? So we have, you spin up a NOVA instance, you can say, okay, that NOVA instance should contain a particular operating system image, right? And then there comes up with that. The corresponding way you have a Trove Guest Image, the Trove Guest Image consists of three parts. It contains the Linux flavor. If you wanna use CentOS or Ubuntu or whatever else, then you can create one. The second part is the database software itself. And the third part is the Trove Guest agent code. So those three things, the Linux operating system, the database software, and the Trove Guest agent, all three things combine to be part of, to be part of a Trove Guest image. And then Trove Guest agent, Trove Guest agent is the piece of code that you use that can actually interact with the database. Now, I said earlier, whether you're using Mongo or Oracle or MySQL, it works the same way. How is it possible? Because each database operates differently, right? The way it is is there's a concept of a Trove Guest agent and what it does is, for lack of a better term, it's a translation layer. So it takes your standard Trove commands like a Trove create and what it does is it translates that to corresponding create for the database that you're dealing with. Obviously, there's a lot more things than that, but that's a general principle. It translates your Trove command to the actual database commands. The Trove instance I saw, I keep using the word instance. The instance is basically a running compute instance or a compute instances, if you're talking about a cluster that comprises your database servers or single database server. A cluster is a cluster data store. I use the word, before I get into data store, I use the word database type. So within Trove terminology, if you say a database type, I have Oracle, MySQL, Postgres, and Cassandra. So each one of those things, the database type is called a data store. And remember, I kind of talked about upgrading within different versions. So Trove also knows about a data store version. So you can say I have MySQL 5.6, I have Oracle 11, Oracle 12, Mongo 3.0, Mongo 3.2. So all those things are data store versions. A configuration group is a grouping of parameters that you can use to kind of tune your running database. And most of you should know a flavor. It's just like it's the same Nova flavor. You can use the various Nova flavors you have created to spin up or to kind of go up or go down if you want to your Trove instance. And before I quickly show you how Trove works, some basic things, just like any other OpenStack servers, when you create a database instance, you can either do it through command line or a graphical user interface. And you can do basically, you have full flavor support. So if you can say you're starting with a M1 large or M1 extra large, then you can keep going up or go down. You have syndrome volume support. So you can start with a small volume and you can keep increasing the size as your database needs grow. You can, using the Trove API, create databases users and create backup and restore from the backup. What I want to do is once again, I find when I'm on the booth, a lot of people are coming and saying, okay, what do you do? What does Trove do? Database as a service? How does it work? How do you touch feel it, right? So probably just spend just a couple of minutes, just quickly show you how it looks in the UI. A number of you, if not all of you would be familiar with the horizon interface for OpenStack, but you may not have used the Trove plugin inside that. So when we talk about deployment methodology and how we do in PUC and production, hopefully this would help you understand that better. So basically if you look at it, if you look at it when you deploy Trove, when you deploy Trove, this is basically when you deploy the Trove plugin, community Trove, let's say, right? So you get all of these things in there. You get instances, backups clusters, data stores, configuration groups, and replication topology, right? Replication topology, basically if you create a master slave, if you wanna just look at those master slave instances, you can click on that and you would see that. And I'm gonna show you how you create a single MySQL instance, take a backup and then create how to create a Mongo cluster. So to create a new instance, just like Nova Computee go to launch instance and out comes this window and you can basically enter the information you want. If you have, now with databases, it's slightly different, right? You can have different databases in different hypervisors or availability zones. So let's say that you have a database in one availability zone, you won't have other databases in different availability zones to kind of protect yourself. So if you want to Trove supports that, you can basically specify the availability zone that you want and you can specify the instance name, that's no different than how you create a compute instance, specify from a database perspective, specify how big your databases, at least the starting value is, you can specify the data store which is the different databases that are available, right? So even though I showed a list of 16 databases, if you take into account the commercial versions, right? You can pick and choose what you want to provide your developers, right? You can, you may want to enable only five or six. So those five or six is available here and same thing in the flavor, right? Depending on what flavors you create, you can do that. One thing Trove does is you can say, if you're interested to get into that is to say, if you have a Mongo database or a Cassandra, you may want to provide it an SSD based one, whereas for MySQL just brought a regular spending disk. If you want to filter it based on it, you can do that using Trove. And Trove has come a long way in the last three, four years based on customer feedback, so it's pretty good. And then the same thing, if you want to say only specific flavors for specific database types, there's something you can do. Obviously, this first screen lets you pick and choose what, how you want to customize your database instance or the database server. The other thing is, when you create your database instance, you can also, at the same time, for the databases that allow it, create a database and a user to operate on that. By default, Trove doesn't create a root user, it's basically you have to create database instances and on those instances you create users with password. So basically what you can do is, you can create a user on a password and then you can provide them the endpoint. And what happens is that when you connect to the database, you have a database name and a user on a password, and you can use that to connect to that. And obviously, if you choose to create a database instance without a user or password, you can always go back in and add it at a later stage. And you can have any number of, depending on how big your flavor is, you can add any number of databases and users. And obviously, Trove creates the database instance in the user's tenant. And then once you do that, if you inspect the instance, either through the CLI or through the GUI, you're also presented the connection string. So if you have developers that are using it, you all you need to do is provide them the connection string. And even if they don't have access to the GUI or the CLI, they can still connect to the database as if you created it by hand. And this tab, the defaults tab, is what I'm talking about. This is basically it allows you to list out or make available all the properties for a given database type or a data store. So different data stores have different properties. And what Trove does it, it gives you access to all those things. And if you want as an organization, you can say, enable all these properties for all my developers. Or you can say, take a subset of this, give it to only my DBAs can access it. The other subset, my regular users can access it. You can add more to it. You can take away from it. It's up to you. You have flexibility. Out of the box comes a number of properties and you can pick and choose. The other thing that Trove supports is the concept of logs. Remember I said earlier that you cannot SSH into the instance, right? So a number of you that have used databases in the past, you have, you install, you launch a compute instance, you SSH into it, you download the database software, you set it up, and then you run it. And if you say, hey, something is going wrong, you want to go figure out what it is, you SSH back into it again, you go and look at the logs. But if you can't SSH into the instance, how do you get the logs? So what Trove does is it exports the logs to you, once again through CLI or through Horizon, right? So since we're looking at a MySQL instance, it provides all the MySQL logs that you care about. In addition to that, the Trove guest log that basically says what is happening from a Trove perspective. You can publish these logs anytime you want. If you want to enable or disable a log, once again, you can do that. But the net net is everything that you want to do with the database server or a database instance, you can do it through the GUI or through the command line. It makes life a lot easier. And you know that by mistake, you cannot do something that would cause problems to the database instance, right? Because it's all done through this, there's not much damage you can cause other than just use it. There are a number of things that this demo is there, but given the time constraints, I'm just going to focus on some other simple things that you can do. If you look at it, these are all the things that you can do. You can upgrade the instance. You can schedule backups. You can attach configuration groups. If you want to create a root user, you can. Resize instance, resize volume. But if you want to take a backup, it's pretty simple. You can very easily do a backup by clicking on create backup. Basically, creating a backup is pretty simple. What happens is just like you do create instance, you can give it a name and what database instance you want to take a backup. It takes a backup. And then the way True works is that obviously the database server instance is created using Innova instance. And then the database itself, the data in the database is stored in a center volume, right? Now the backups are not stored in center. So what happens is that when you say take a backup, whatever approach you have, depending on the database type that you take the backup in, the backup data gets taken. And then if the database type allows for streaming backup, the backup is streamed, otherwise you take a local copy and then you move it. But the net net is the data gets taken, the backup is taken from center volume and stored in Swift. So for True, one of the requirements if you want to use backups is basically you need to have Swift enabled. So you take a backup in Swift, then you have the ability to look at all the backups and because the backups are stored in Swift, when you delete a database instance, the compute is gone, so is the center volume, but the backups are still there. So the net net is you may create some database in the past, you can do some development work, you can take some backups, and then if you want to delete those instances, but you still want to go back to the schema or the initial things you had created, you can always go back to that and you can use it to restore and create a, create a new database. Now, we kind of looked at it just a small exposure to how we create a single instance and a volume. What I want to do is also just a slightly different way to say a Mongo cluster, right? So remember I said it works the same way, whether it is a MySQL or a Mongo or a Postgres or Oracle. So if you want to go through clusters, just like launch instance, you click on launch cluster. I don't know how many of you are familiar with the Mongo cluster, but basically you can just provide the name, the data store, which is in this case a MongoDB, a, the flavor, the volume size, and Mongo works in a slightly, basically the Mongo data, when you talk about cluster, you have either a number of shards and each shard has got a replica set. So basically what you can do directly using Trove is basically you can create the Mongo shards and replica sets in a single operation. You basically say how many you need and then what happens is in this case, I've chosen one shard and three replica set instances, right? So basically if you look at it, it is a compute instance of one gig RAM, right? It basically there are three instances. Obviously given the factors of video, it runs really fast and real life will probably take a little bit more than that. But if you go take a look at the Mongo cluster, you would see that the cluster is there and also the instances are there. But the good thing is from a Trove perspective, you can deal with it as a cluster, you can grow the cluster, you can shrink the cluster as a cluster as opposed to a single instance. And if you take a look at the compute tab, then you can see that the actual cluster instances are there, those three instances are there. And in addition, Trove takes care of the, for those folks that know about Mongo, Mongo has a concept of a query router and config server. So it creates all of those things behind the scene for you. But take up it this way, I have spoken to a number of customers, they say, hey, you know what, single instances are easier. If I'm gonna create clusters, I gotta go back and spin up all those instances, set up the networking, set up download the software for every single thing that I want is pretty painful. If you go to the community, you get the Trove, deploy it. Then, you know, with just one command line using your CLI or through the GUI, you can very easily create however big a cluster you want. But more importantly, you don't have to worry about the details of how you grow or how you shrink. So if you wanna grow the cluster, it's pretty simple, if you wanna shrink it, it's pretty simple, if you wanna grow the cluster, all you would need to do is, you know, click on the grow cluster, add instance, and you can basically add new data instances, new query routers, new config servers, it's pretty easy. And I just wanted to show that to you so that you have a sense of what exactly, you know, how does Trove work? Because that is one thing I hear all the time, what is Dbass, how does it work? So for those folks in the audience, if you are not familiar with Trove, you may have seen Audi as an action, but if you haven't seen Trove, hopefully this gives you a sense of single instance backup cluster, how does it do? Like I said, Trove does a lot more things and it's very easy, go to the GUI, click it, and you can use it. And then coming back to the main topic, which is the best practices, right? How does Trove work? If you, let's first look at the basic Trove architecture, right? So when you look at Trove database architecture, this is the way it is, and it is very similar to other OpenStack services. So it basically has got a API service, it's got a conductor service, it's got a task manager, and in addition it needs a message bus and a metadata database for the operations. And the picture on the screen, it kind of contains two boxes, right? So there is a box, which is the OpenStack box, and if you look at it, it's got the OpenStack services, right? It's got the compute sender, it's got Swift for the backup, it's got Glance for the database images. So if you have, so far in the demo, we saw Mongo and MySQL. So if you have a Mongo and MySQL, those two images would be stored in Glance and then you have Neutron and Keystone, right? So basic OpenStack services, and in addition to the box on the left, you see the Trove API, Trove task manager and the Trove conductor. The, when you deploy Trove, let's say you go to community, you grab the Trove, you deploy Trove, you get those three services, and the Trove API is the service that you work with, the way you say, you know, Trove create, Trove backup, Trove delete, Trove grow, Trove shrink, whatever, right? That's the one that handles that. And then basically it uses the message bus, to kind of pass the messages on, and then task manager is the one, similar to other services, that does the bulk of the work. So it takes all the work and then communicates with the different things. So for example, if you're going to say, you know, create a MySQL database, you know, particular flavor, particular syndrome volume, things like that, you need to make sure because the folks here understand the access a user has with an OpenStack is governed by their tenant quota, right? So if you have only so much tenant quota, and if you keep creating instances, it's going to eat into the quota. So you want to make sure, or rather, Trove wants to make sure that you have the resources to do that. So when you say create, the task manager makes sure that all those resources are available. And if they are available, it continues to create it. If not, you get an error. And then the last one is the Trove conductor, and the Trove conductor, basically if you have running instances, if there are things going on, it goes through the conductor, through the message bus into the log. Each of those three services, API, task manager, and conductor, have a particular log. It is on the Trove controller. So if you want to look at it, you can go back and look at those logs to see what's going on, to see what's going on. And then talking about best practices, we have had a chance to work with a number of customers, large companies and small companies, and they all want to try out Trove inside their OpenStack environment and see how it works. And like I said, I'll be, I have a few thumb drives, 30 gig thumb drives that contains a DevStack and a Tesoro environment in their Trove environment. So if you want to deploy it, so typically this is what a POC configuration would look like, and based on best practices. So you have your OpenStack here. So you may set up your OpenStack in HA, and your OpenStack you may have, once again, your RabbitMQ in HA, and you may have an infrastructure DB, and typically it's MySQL, right? So you have your OpenStack, it's all right here, everything in HA, right? Now from a Trove perspective, you may want to keep it as part of it, or you may want to keep it isolated. So what we have seen customers do is that you can spin up a Nova instance, and you can grab Trove, and you can deploy it in there. So Trove strictly runs as part of your Nova environment, right? You spin it up, you put it in there, and if you look at the picture earlier, Trove needs a metadata database and a message bus. You have two options, you can either say Trove, use the MySQL database that your OpenStack uses, or you can say Trove use the RabbitMQ that is part of that R, because you're doing a POC sample environment, and what you can do is you can basically say, you can create your own RabbitMQ and a metadata database just for your POC so that you don't touch your main RabbitMQ or things. So many times when we work with folks that want to try it out, they're admins, and maybe there are some OpenStack admins here that you don't want to let people use the main RabbitMQ or metadata database. If that is the case, you can choose to have your own RabbitMQ or your own MySQL database, and all you need to do is tell Trove, here is where it is, and you can use it, right? And obviously you have a number of tenants, and what happens is when you say create a Trove service, that tenant has access to both the Trove management network as well as a tenant specific network. So all you would need to do is from your perspective, if you want to try Trove out, basically spin up a virtual machine. All you need to do is go to your OpenStack, spin up a Nova instance of sufficient size, like a large or whatever it is, extra large, deploy Trove in there, and then have your own RabbitMQ and have your own MySQL database just for the purpose of Trove, and you can use it, and once your POC is done, you can kind of clean it out, so it makes life a lot easier. And we have some customers that are using it, Cisco's one of them, when I did a similar presentation in Austin, and the folks from Cisco were there that kind of worked with us, and we kind of talked about it. I wanted to kind of talk about how, we talked about the POC environment, which is pretty simple. When you talk about production, it's a lot more complicated, right? So if you look at it, you can have a within OpenStack region, you can have a service cloud where you can have your Trove services in HA, and you can have your OpenStack services, and what you can do is, this is the way they have done it, but you can choose it in a different way, but basically they had a separate tenant cloud and they put their instances in there, so when instances get created, those instances get created in the tenant cloud, the advantage is that if you are a single enterprise, like a number of customers are, it's not an issue, but if you are providing services to a number of groups, then by putting it in a separate cloud, what it does is the OpenStack operator doesn't have access to that, only your own group has got access to those instances, and only if you want to provide your OpenStack admin access to that, you can enable that access, so they can go back and look at their instances. You can either put it in the same cloud where they have access, or if you want to really segregate that, this is one option, they have done it that way, it is something you can look into it and see if this is something that you want to do, it's kind of interesting, it works for them, something to keep in mind. So, and obviously you need the message bus to communicate back and forth, and the message bus is in a DMZ, and if you're looking at, okay, great, how do I deploy Trove in an HA configuration, because when you talk about a POC, you can say, okay, what I want to deploy Trove in a NOVA instance of sufficient size, I can create a bunch of Trove services to use them, but in a production setup, or even in a staging setup, you want to have Trove in an HA configuration, right? So in an HA configuration, what you can do is basically you can have one way of doing it, I'm not saying this is the way everybody does it, I know a number of customers do it this way in production, you can definitely do it this way, you can have a load balancer in their HA proxy, and you can have Trove services, basically a number of virtual machines or physical machines running that has all the three Trove services, right? The API, Task Manager, and Conductor, all running there, standing behind a HA proxy, and correspondingly for the metadata database, you have two options. Once you go to production, once your organization has said, hey, you know what, we tried Trove out, we did it in staging, everything seems to work fine, we can put it in production, because at that time, Trove could be a first class application, right? So your IT teams would let you store the Trove data access, Trove with the main metadata database or your main rabbit MQ, that is the case, you can use that, but if you decide, you wanna still keep it separate, then for your metadata database, the MySQL database, you can put it as an example, a Galera cluster, and you can put it behind a HA proxy load balancer, and Rabbit MQ, once again, you can set up a number of Rabbit MQ instances, and you don't really need to do an HA proxy in there, I think there is, it may have been dissolved right now, there were some issues with the Rabbit MQ and HA proxy, so what you can do is, in a Rabbit MQ configuration, you can specify all the servers it's running in, so it handles that internally, so you can just do it that way, meaning set up your Trove services in, multiple Trove services, put it behind a HA proxy, put your metadata database in a Galera cluster or something like that, behind an HA proxy, and set up a number of Rabbit MQ instances, and have it work that way, so POC, Spina Ponova instance, put it all in there, use it for your testing, production staging, put it in an HA setup, and do it this way, there are other ways of configuring Trove, but I just wanted to give you a sense of what has worked for other customers in real life, and if you're willing to try that, this is something that will definitely work for you, and there were some requests saying, hey, you know what, Trove is there, in every cycle, new features are coming in there, what is coming in Newton, so basically in the Newton, there is this upgrade support, so if you have patches for your Ubuntu, or CentOS, or Red Hat, or whatever Linux systems you have, or for the databases themselves, if you have bug fixes and things like that, and you want to upgrade things with that, so there's upgrade support, there's more usability improvements, like I showed you, grouping of master replicated pairs in there, so things like that in there, there is clustering improvements, more clusters being supported, and then there is, I didn't really get into it, but basically we talked about availability zones, you can basically say that when you create a master slave pair, you can put the master in one availability zone, the slave in another availability zone, now if you look at OpenStack, when you create your AZs, it has a tie into your hypervisors, so that way what you can make sure is that the master and the slave are two separate hypervisors, so if one of them goes down, the other one is still available, so that is something you can do, and there is better Postgres SQL support from the community, and same thing with DB2 Express, I don't know how many of you are interested in DB2, but if you are, you have better support, and same thing is there were some issues, I believe, with the quota management, and then there is, they have fixed it, so it's easier to do that, and obviously I'm not spending too much time on these points and greater details, but if you want to know more about the specific features, what is being done in Newton, and what is going to come in further down in Ocata, then there is a session by the Tro Ptl, tomorrow at 1.50, in 1.17, I guess somewhere here, or maybe in P2, so basically talks about what is coming there in OpenStack, Newton, and then in Ocata. Wow. We have five to 10 minutes of time available, so I'm happy to answer any and all questions. So there is a microphone there, I think if you could do that, everybody can hear it plus it's going to get recorded in there. I have a question. Sure. Can I use heat to deploy databases? Not right now, I mean you can use heat, but Tro does not use heat, Tro uses its own, so if you have your own heat script, maybe you can use that, but Tro doesn't support heat right now. Okay. And can I grant access to databases through security groups? Yeah, so when you create a database instance, a security group gets created out of the box, what happens is only the ports that are needed are enabled, but you can control it, you can control security groups. I would just say be careful, but yes, any other questions? Yeah. So the question was, what happens with backups is the instance being shut down? It, so it's a good question, so it depends on the database type. Tro, it's basically we take a backup, we don't take a volume snapshot or something like that. So different, we have different databases, and depending on the database itself, if the database supports a warm backup or hot backup, then that it works that way. Sorry? So basically we use a database technology, so if you take a look at a backup where it takes a look at the transaction log and whatever has been done, has been stored in the backup, it will be consistent that way. So one thing to keep in mind, I didn't specifically say it out earlier, Tro does not rewrite any of the database functionality. So if you take a look at going back to MySQL, so for MySQL, we out of the box, Tro uses per cone extra to be backup, but if you want to use, for example, MySQL dump, you can do that. There are things called strategies and you can pick and choose what you want to do. We don't rewrite any of the database specific code because the database companies themselves have spent a lot of time and effort, so we can reuse them. So whatever behavior you would expect where you to do a per cone extra to be backup or MySQL dump on a MySQL database is the same behavior you would see when you take a backup using Tro. Sorry, there was a question there. Yeah, just a question related to the database engine. How do you maintain it up to date? So assuming that there is some patches to deploy on top to address security breaches, for instance, how do you do to maintain the engine always up to date? So there are two parts to it, right? The Trove community itself provides the update, upgrade mechanism I just talked about in Newton. Where else? Where if we have a new guest image, we have the ability to upgrade your running instance with new guest image, but just one of the company I work for, we provide regular updated guest images and we provide the tooling to upgrade it. But if you're going to use a community Trove, you can use a Trove functionality, but you will have to create up to date guest images and use that to keep your databases in sync with that. Yeah, go ahead. Where are you going to wait for test it? So two ways. So the question was how do you test Trove? There are two ways. If you take the thumb drive I provide, it's got DevStack, OpenStack, and Trove already installed. You can just copy it into a laptop and test it out. Or if you have your own OpenStack available, you can either download it from the community and you can deploy that. Or if you want something easier to do, you can come to our website, there's a free trial you can download it, kick the tires either way. Sorry. In terms of locking, when you, I'm not sure I follow the question. So when you create a Trove instance, Trove automatically creates a Nova compute instance and put the database in there. It has an IP address associated to that, so that's what you use. Yes, so you can, yes. So if you're talking about isolating instance, remember I talked about availability zones and hypervisors and things like that. You can take a look at, when you go to, if you are familiar with the OpenStack ecosystem, you can look at the dashboard and figure out which is being heavily used, which is not being heavily used. If you have a proper OpenStack with multiple hypervisors and you can look at what is available, you can pick and choose that availability zone or hypervisor or the compute and you can create your Nova instances there. But keep in mind, if you are talking about single instances or things like that, that's great, but if you're talking about clusters, you may want to spread them out and depending on how big your infrastructure is, sometimes you may have that clash, but it depends, it is a function of how much space and flexibility you have, yeah? There's a question at the back, yeah. Trove, okay, Trove uses CIF. Trove runs on the OpenStack control plane, but Trove uses Cinder and Swift for storing the database data and storing the backups. And if you want to use, and basically Trove uses the public API for Cinder and Swift, so if you configure CIF as your Cinder as well as Swift, Trove would work with that. Yes, yeah, you can do that. That's something that's new. Yeah, yeah, that's a good question. Right now, we are looking at the community, when I say V, the community is looking into it, but right now what happens is, Nova has got a functionality called Nova Rebuild, so basically you can take a VM and put a new VM in there, so what happens is that we use that functionality to product here a new instance based on image, and we don't touch the data, but when you bring it up, there is downtime. The actual downtime per database, if you will, is limited to how much time it takes to bring it up, so it's pretty fast, but today you're right, today because we use it that way, there is a downtime. So we probably have two to three more questions. I'm available to talk outside, I guess, the next person will have to come in there, so there are two questions, go ahead. Okay, so the question was how do you do monitoring? So there is no module per se, it is a functionality within Trove called module management, and there is documentation that basically specifies how do you create a plugin for the monitoring tool of your choice. Let's say you want to use New Relic or Nagios or CollectD or whatever it is that you want to do, or Oracle Enterprise Manager, right, if you want to use Oracle, so you basically create a plugin using the Trove documentation and use the module management API to load it in, it's pretty straightforward. Yeah, it is non-disruptive for the instances, but when the Trove itself upgrades, keep in mind the instances are basically your MySQL 5.6 or something like that, as long as the next one supports it, it's good. So there are two ways, I mean if you use the Community Trove, then you will be upgrading it as part of the OpenStack itself, but what we have done is not a plug for my company just to give a component contrast, what we have done is we found that upgrading OpenStack is complicated, it takes a long of, and a number of our customers have chosen to jump over one OpenStack release because of the time and effort, so we have made sure every release that we put, and we put roughly three to four releases a year, it's backwards compatible all the way to Juno. So in your case, if you are in Juno, Kilo, Liberty, Bitaka, whatever it is, you can use the latest and greatest Trove from Tesora, and what happens is that when you upgrade, we provide upgrade scripts, you can just run those upgrade scripts, and obviously there's a downtime during that time, but once your control pane is up, your instances are available. Sorry, you're saying? Exactly. So do you have time for one or two more questions or do we need to close? No? Okay, so I'm available, I can be available outside or I'm also available at the booth, and you can do it. Oh, thank you, thank you.