 Good afternoon. My name is Vikas Berkes. I'm the software development senior director for Oracle OpenStack for Oracle Linux. I know it's a mouthful. So I've just to give you a very brief background. This, for me, is I actually been at Oracle for quite some time. I worked in a database group for a little bit. Then I did Oracle VM for a little bit, and I'm doing OpenStack at this point. And we've been spending a lot of time trying to go to figure out what are we going to do with the database to get the database into OpenStack. So we have a couple of paths that we're following, and this is one of the paths that we think is very promising, and we really want to do this. Now I have to remember how to... Okay. Safe Harbour Statement. Whatever I say can be wrong, and you can't tell me about it. Okay. So to deploy an Oracle or any application, especially the Oracle products in OpenStack using Murano, there's a couple of things that we're going to really need under the hood. So to start off, the basic, obviously, needed OpenStack distro, right? So currently we just started the beta, we released the beta for Mitaka in July, and the production is going to go out, store this year. So you're going to need something that's based on the Mitaka, and you're going to need Oracle VM server. So note, KVM is not certified for any Oracle product. That's not the same as saying it's not supported, it's not certified, right? So you're going to need Oracle VM server, you're going to need Mitaka one. Also for the database specific, you're really going to need Cinder volumes. You can do ephemeral, we've tested ephemeral, it works fine. We just don't really want people to run production on ephemeral. On a dev test environment, that's fine, but if you want to go production, really you need to have Cinder. For the application catalog entry, we are using ASM to manage the database storage, the Cinder volumes, to automatically make it easier for the database to see the devices. Also, please don't use the LVM driver for Cinder for production. Again, it's fine for dev test, it's fine to kick the tires, but for production you probably want to have a real storage behind the Cinder. This is easier, okay. So why did we go Murano? So one of the couple of big things that jumped out at us when we started going down how to get the database in OpenStack is, our release scheduling is very different than the OpenStack release scheduling, right? So the database relieves one to two years or whatever, right? And I have patches coming out all the time and we wanted to be able to decouple the two because you really don't want to have to wait for either the next database release or the next OpenStack release to be able to get something done if you need a new database. And also it allows us to really expose all the database features. I mean, why do people use Oracle database? Because of its features, right? It has a lot of features. There's new features getting added by the database group all the time. One of them is just this new REST API that they're adding for the management, right? So we want to be able to expose all that easily and at any point in time if they add a new feature, we want to be able to expose it. And lastly, but this is probably one of the bigger reasons we went to Murano Road. We need something to build on, right? So the database is step one. What about the Oracle products? You need to have something to build on, like you need building blocks. We need a platform. So Murano allows us to start working up the stack. So I'm not going to talk a lot about Murano's architecture or Murano in specific. I'm just going to touch on a few things. And the one thing I want you to note in this one is if you look at Murano, the only thing it talks to is heat, right? It doesn't talk to Nova. It doesn't talk to Neutron. It doesn't talk to any of the others. It just talks to heat, which is important for us because we want to essentially be able to minimize our exposure to the bottom. We'll see why. So if you look at the layers of extraction, at the top, it looks like a building block, right? You start at the top, Murano. It's a data in the logic, then at heat, which is data only, which then goes and translates into Nova and Neutron and all the other services. So we want to move up the stack. So the heat orchestration layer, right? So heat is sort of like as a graph of resource nodes. Resources are consumers or providers of resources. Each resource node can be configured according to what the API of the underlying services, no more, no less. So we can't expand right at the middle all of a sudden this heat, the notion of what is Neutron port is without actually changing the always Neutron ports API. So Trove is similar, right? Trove is just always Trove instance. So it has an API and that's what it's going to expose and that's how the heat is going to see it. And it's great because that allows you to do that. But with Manila, Murano, the database server is sort of just seen as just another vanilla compute node, right? It's from heat's perspective, it's just another compute node. It doesn't see the differences. It starts a network, starts the server, starts the volumes. No difference. So with Murano's approach, the computers and providers are at the application layer of the packages. So it's sort of like a OO type layer language you use. So the application can either extend or use one of the other package types. So for the application, we extend the Linux application, which then depends on a SQL database. And the SQL database can extend that SQL database. So you can make this as tightly integrated or loosely as you want. So we can start really when you start building the stack, you actually have a way of starting to depend on other pieces. One other thing that Murano allows us to do is with the Murano agent. So a lot of the things that we need to do is we need to reach in when you configure the database or the application into the guest to do configuration. With the Murano agent, it allows us a path in the guest to do that initial configuration, set it up, and essentially then expose that to the next level. So no, the Murano agent will be required for the Murano database application entry, because as I said, we actually do reach into the guest to do some configuration. So Murano versus Trove, and I mean, the reason we went through this is every single time we start talking to everyone about what we're doing with Murano, the ask is one or Trove. So it's like we don't have anything against Trove, we're actually investing in Trove as well. But we see a different use case we want to solve as well that Trove will not address at this point. So Trove is great for this, just give me a database, right? I want a database, I don't care what it is, just give me a MySQL database or whatever. And it's perfect for that. It's perfect for the, if you, and the problem is, is like when you run into things with changes, right? The API has to change, it can take a long time, we have to go through a lot of process. We have the Murano side, if a database package needs to change, we can change it and ship it, right? So let's say the new Oracle 12 CR2 comes out. We can immediately start releasing that out of sequence. It also starts giving us the framework to bold on top for other applications for Oracle, right? Again, no one runs a database, people run applications, but the application needs the database. So we want to, so we're starting at the lowest level, the database, once we have that fully done, then we will go to the next level and start running the applications. So, and also the last point is like the abstraction layer. One of the other problems is what we'll find, what we know with the Oracle applications is when they depend on the database, there's one or two of the application, Oracle's catalog to specifically do this. They reach into the database and do changes. They need to actually affect the database deployment. That's very difficult to do through Trove. You can do this easily enough, Murano, when you do that layering stack. Okay, so let's switch gears. So I have a demo. I will hope it works, because everyone probably want to see demos. Not that one. Let's see if I can get it. Oh, here we go. And I'm going to start it. I'm going to kick it off at this point. And the only reason I want to kick it off right now, even though we'll come back to this, is this is actually live, so it will clone the database volumes, which takes about 10 to 15 minutes. On the ZFS we have running this on. So if we start it off now, when we come back and we're done, we can actually go to the next levels, next steps. So, it's just odd to see it over there. Okay. I can't see where I am. Applications. Ha, that's why. There we go. So this is a normal Murano catalog that everyone knows. So it's for Oracle. So just a quick note here. So there's two of these. Oh, I can see myself. There's two applications, the Oracle database and the swing bench. So when we did this, we just needed something to bowl on top of the database, right? The swing bench is a very simple load generator for the database. That's not the point. And we just needed a client to the database. Otherwise, you'd have a database and so what, right? So that's it. No one runs a database, run an application. So we just packaged up swing benches. It's a very, very simple thing. It's actually just a Java UI. So I'll have to go into X to actually run it. And we made the swing bench then depend on the Oracle database. So a quick deploy. Come on. Not clicking. That's not good. It's not clicking it. Hello. Ah, there we go. It just took a while. So we are at the application which needs a database server. So the Oracle database 12c. Just call it. You can assign a floating IP. We allow that. In general, we would suggest people don't actually assign floating IPs to their databases. Next. So here's the crux of it, right? So if I'm going to click down on it. So this is what's currently in there. Single instance. Single instance. Each own rack. Currently only these two are support. We only support these two. Single instance and single instance, the HA1. The number of... So PDBs. So people probably seen on the GitHub trees, there's a Oracle PDB connector. This is similar to that. And this is not what I'm going to demo. This is not really what we're focusing on. So Oracle has two modes of operations, right? It has a PDB, which is like the pluggable databases. And in other cases, you just run the Oracle database as the normal Oracle database. This will just spin up the Oracle database as a normal single instance database. Scroll down. And all we need to put in here, the defaults we can keep. The only thing I have to put in is passwords. So we do require hard code. We require you to actually give us secure passwords. So it will have a check for that. For both the system and sys user. All right. SwingBinge comes back and says, OK, I have my dependencies. Let's go. OK. So this is ready to deploy. So I'm going to deploy the environment. And it should go and start cloning. There we go. So this takes around, I would say, 10 to 15 minutes. So we can flip back to the presentation. Where is the presentation? OK. So the Oracle Database Murano catalog entry, the architecture. So I'll quickly go through what we've done here and what the architecture is. And so for the architecture, when we started down this road, we decided we want to build on what Oracle already has. So anyone that ever had actually ran Oracle databases on the Oracle VM or any virtualized environment would be very familiar with the Oracle Database template. It's something that Oracle have already had for many years. It's been battle tested. This thing is running in production at sites already, many, many sites. We're running really big databases, both single instance rack, whatever. The only thing we had to do this template, as you can see, is we had to change it like there were small changes we need to do. One of them was the UID we changed from Oracle, right? Because it was clashing with Cloud in it. So it's not a big change. It's not a new template. We just took what we have and we decided that's the way to start for. So the template consists of two disk images, right? It has the operating system and application disk. So that brings up an interesting question that we want to ask the community for feedback, right? So the way that all the older templates work is to have this separation of OS and application. Is that something that the community is going to have a problem with? Is people want to see one glance image? Or even we can take that a step further, because we heard from the guys that's running these templates, they would like to mix and match versions of the database and OSes. So would it be better for us to then make a database catalog or catalog entry for the OS and a separate one for the database? And the database will then pick. You can then pick and choose, right? That's one option. So we're going through this. And we're looking for feedback from the, essentially from the users in the community to sort of guide us a little bit here to tell us which direction they think we should go in. Because it's not something we're doing to force down your thoughts. It's just something for you to make your life easier. So we want you to give us some feedback, tell us which you think it will be better for you. OK, so stepping back, let's look under the hood of this thing. So the database installation and configuration, it's all done with this one script inside the template, right? Bolt cluster, which is written by Oracle. And this is inside the template. The bolt cluster is really that's been used all over the place. Every single database template that will be deployed today actually use bolt cluster to build out the whole. It can build out single instance, single instance data guard. It can build out rack. And when it bolts out rack or rack with data guard, it will build up all the VMs. So if you give it like, I want to have a eight-node rack system, it will actually, you give it all the parameters for the VMs, all the networks. And it will go ahead and it will spin up that eight rack nodes. So it's well tested. I mean, this has been running forever for us. So most of our deployments that we test is using this as well. For storage, as I mentioned before, we strongly suggest cinder volumes. But they haven't tested ephemeral is OK. What we would suggest is use something like CIF or so, so that your ephemeral is shared. And this comes in, especially on single instance, it's very important. You want to be able to live migrate. So you need to have shared storage. On rack, even on rack, we would suggest using this, you need to have shared storage so that when you actually want to move nodes around or whatever, it makes sense. ASM, as I said, is we're using ASM to present the disks, the cinder volumes to the database. We do allow you to actually specify the redundancy level. And as I mentioned here, be careful when you specify external redundancy. We had many calls in the past that goes like, I didn't know exactly what that meant. That means you actually take responsibility for the disk. It will never fail. We suggest using most customers either have redundancy that's external. That's good. If you don't, pick the high or normal. So we did the database, right? It's still very early for us. I mean, as you can see the demo, this is early days for us. We started this maybe, I would say, three, four months ago. We started down this path with the database. We will release a full tech preview for the database very soon. It will go out with the 301 release. Note, the tech preview is only for the application catalog entry. The database is fully supported. Anyone can run the database. You can go, run it today under OpenStack. As long as you run it on a certified platform, that's fine. We will support it. It's just you need to actually be able, you'll have to do a lot of things by hand. There would be no way to just get it as a service. So it's really the database as a service part, which is the tech preview piece. So for what's coming up for us is we really want to work with the Murano community on enhancements. We ran into a lot of limitations and issues around. The database is a fairly complex app to deploy. It has a lot of moving parts. So there's some pieces that's missing or some of the UI things that we really need to actually address. So we would like to work with the Murano community more to that. And it will help in the future with other apps. Because as we start moving up the stack, the applications get more complex, not less complex. And lastly, we really, really, really do want to get feedback on this. We want people to go play with this. Tell us what's the issues you've run into. What do you want to see us to do? What do you want to see differently so that we can actually make this work for the vast majority? Deploying Oracle products in OpenStack using Murano. The limitations, as I mentioned. There's limitations with the database running it on OpenStack today. This is just a very small piece. There's a couple more. But these are probably the ones that you'll face immediately. It's like when you spin up a database today under OpenStack, it's a VM, right? But it's a black box. And this VM can have maybe a thousand users hitting that database. So your CPU is pegged at, like, 80%. You would have no idea what's going on because you just see this VM spinning up at 80% CPU, using a lot of IO. You have no interaction with the database at that point. So there's no solometer interaction. So one of the things that we are, which is on our roadmap, is to work with the database group once to how it's also interested in us to get all the stats from the database into solometer. So when you look at your horizon dashboard and you see this VM spiking, you can actually say, oh, wait a minute. There's 100,000 users running in this database. So it makes sense, right? So that's one of the issues. The second one is really around rack. So Cinder has multi-attached volumes already, but Nova does not. Now, there is ways around it. You can move iSCSI volumes into the VM, or you can use NFS. But ideally, we would like to use Cinder volumes and attach it to the VMs, right, for rack. So the multi-attach is something we do think it's, and we're going to, with one of the focus areas for us, for this cycle as well. We're going to work with the community on that. More of some limitations, really, for running the database as is, is memory armor commit is not supported with the database on the OVM server. So if you run OVM server, we don't even allow you to do a memory armor commit. And in general, if you do a memory armor commit and you call support, they will tell you that's not a good idea. So we really do not support memory armor commit with the database. Ephemeral storage, that's fine. It's backend for live migration, and it's okay to use, but for the database, we want to use something more performant, like a Cinder volume to a real backend. Database-specific rack, as I mentioned, rack is not yet supported because of the Nova multi-attach issue. And then, even when we get past that, CPU overcommit is not supportive rack. So if you want to run rack in any virtualized environment, you cannot overcommit CPUs. It can lead to notifications, so they don't want you to do that. Okay, so we can spin up a database. That's great, right? So this is just, where are we going with all this? Our end goal is really to get all the other Oracle applications into OpenStack. The Oracle database is really, really just the first step. We've already started to work with the other Oracle product groups to get this done, so we're working with them to actually add application catalogs. The problem is, as I mentioned, an Oracle, it always works. You start with the database, and then you're bold. So before the database is fully done, they can't really support anything else, right? They have to have the database done first. So that's why we are really focusing on the database at this point, to get that all done in a squared way. Once we have the database there, then all the other apps will follow. We intend to use the same model for all the applications that we did for the database, meaning we'll use the current Oracle application templates that's already available and people can use. They test it, they're well-defined, and we know how to configure them. So we'll use those as a starting point to actually then bring them into this Morana application catalog entries to make them all available. And the other thing is, lastly, we do want to work with the community on a reference architecture for the Oracle database. I think that's very important, not just for us, but also for the community to understand what would be a best practice in the reference architecture for running the database under OpenStack. Okay, so now we can hopefully the database has spined up. Let's go see. Oops, deploy failure, that's not good. Oh, great. See, that's why they say don't do demos live. Okay, well, that's a problem. This takes way too long to do again. Damn. Let's see if I just delete it and redeploy it. I'm not sure why I did that. It's funny, I tested it this morning. Works fine. Shouldn't have tested it. Well, while we wait for this, any questions, this is going to take a while to actually deploy. But I would like to show you this, and if I can't get it to work now, you can come by the booth and I can actually talk to you and I'll show it to you. You can take a one-on-one through this. That's a pity. Yes. So what it requires is a certified platform, right? And all the database or any Oracle product is certified on Oracle VM server. So, and currently the only OpenStack distro that supports Oracle VM server is Oracle OpenStack for Oracle Linux. Yes. So support, the way that it works is if you run on a non-certified platform, right, and you phone support, if they already seen this certified platform and I have a fix for it, they'll give you the fix and I'll help you through it. But if it's something that they have never seen or something that makes them to believe it's something with the environment, they might ask you to reproduce it on a certified environment. So they're not going to tell you, hey, sorry, Mr. Customer, go away. That's not the intention. The intention of the certified is that's where we tested it, right? We know what that works. We have the debugging capabilities to actually go in and see it. So that's when we say it's certified. So when you do it, so the Morano application catalog is split in two, right? So you have the application catalog, which is just the YAML and the zip file, right? The Oracle pieces are still only supplied by Oracle on eDelivery because those are licensed pieces. So you can go download those glance images and upload it into Glance, and then you can deploy it. So the Glance image is like, it will deploy on anything, right? It will deploy on KVM. It will deploy on Oracle VM server. That's not the piece that's certified, right? The certified is the Oracle VM server. Oracle satisfies OSS and hypervisors. And the hypervisors that certify the Hyper-V and Oracle VM server. Yeah. I'm sorry? The Solaris one? Yeah. Solaris, I'm not sure if Solaris ships Morano yet. I think they have done some work with Morano, but I don't think there's Solaris distribution today. Ships, OpenStack, I don't know if they don't. So Solaris don't ship Morano. So that would be the problem that you're going to run into. I don't know. So the question was the OpenStack Solaris distribution. So currently they do not ship Morano. And he was asking his plans, and I'm not the product manager. You're going to have to ask the product manager for that. See, so that's one of the reasons we wanted to talk... Oh, sorry. The question is, he's asking about patching. So Oracle releases what they call a CPU every quarter, the patches. So that's one of the reasons we went with Morano, right? Because you can actually then... If there's a new CPU template, you can use that new template immediately. There's no way to whatever. Also the patching, once you run the database like this on sender volumes, it's normal as if it's like running in VMware or in OVM or in bare metal. You patch the database as usual. There's no difference. Yeah, you can do that. You can use a new template that's already patched and then you can actually split up a new database. Unless you run that rack, right? With rack you can actually patch and with no downtime. Yeah. I cannot answer licensing questions. I'm not a product manager, sorry. Licensing is not my field. A question. So first of all, on behalf of Morano Community, you're referring to thank you very much for presentation and you've got our help if you need it. Oh, cool. And the question. From your point of view as a developer of Morano Application Package, how complicated it was for you to learn the YAMLs, the programming language, all that stuff? So it wasn't complicated learning it. It was complicated finding documentation about it. So that's, I would say, the biggest thing that was what really hindered us is we actually ended up looking at all the apps that's already on GitHub to figure out what can we actually do because documentation was really sparse. So it wasn't really learning the YAML. The YAML was fairly easy to get our heads around, but then it was like, okay, what calls are available, right? Because you have the D, the library, and that's not very well documented. Thank you. And the second question, are there any plans to publish the package which you have made to the Community Application Catalog on the apps.openstack.org? Yes, there is. We will be publishing this on the GitHub repo. Yeah, we do. Absolutely. This is done under their patch license. The tech preview will actually ship as... Yeah. Well, so Oracle, the Oracle OpenStack for Oracle Linux are included with Oracle. Linux, it's free. You can download it and use it whenever you like. The only thing we charge for support, if you want support, all this is all free. The only thing that you will have to pay for is the Oracle Database. Any other questions? We can try this. Yeah? Yeah, I can hear. Yes. Yes. So if you already have an Oracle Database, most of the applications will have like a connection string requirement, right? So you can use that. But yeah, so if... And this is something that we are planning to allow so that when the applications comes into the catalog so that you can actually specify you want to talk to an external Oracle Database or you want to spin up a new one. That is something that we definitely cognizant about because... Yeah, we have to get the database done first, right? So we can actually start doing the layers. Then the next layer up, so the added database, they will actually be able to use this one or they go like, oh, well, you want to use an external database, do that one. Yeah, we will do that for Exadata and so on. Yeah. Any other questions? Okay, I'm going to retry the demo for those who want to stay around. Otherwise, please come and just look me up. I'm at the booth most of the time. Unless I actually have to run out to meetings and so let's see if this will work. I don't know why it failed. Thanks. Even though I didn't get the demo to work.