 Awesome, so this is working. Hi, and welcome to our talk today on curvature in Zanabe. It's actually great to see as many people as we can actually in here. Hopefully you've had as good of a summit as we have so far. We've had so much interest actually in this so far. It's been really good. So, well that's not working at all. So, today we're going to talk about how we got here, who are we, and then we're going to move on to describe curvature in a little bit more detail, talk to you a little bit about Zanabe, and then we're going to open up some questions at the end because we know a few people have been asking quite a lot of questions about how we've built these tools. So, a little bit about us. We are a group of four undergraduates from a university in the UK working as software engineers at Cisco Systems. We're over here actually as part of our degree. So, we've been sort of chucked in and sort of left to do our own thing and it's been a lot of fun actually and we've really enjoyed the opportunity to be able to work for Cisco Systems. So, when we first arrived actually at Cisco, we... Oh, is it working now? Awesome. So, when we first arrived at Cisco we were sort of chucked in at the deep end really with OpenStack and sort of told to play around with it. We started playing with Quantum and we were doing some research actually into sort of the networking side of things and actually we started playing around with VMs and servers just throwing small little Python clients on them and siphoning data out and trying to visualise it and we lost the cropping actually on this picture but what you can see here is one of our initial concepts where we were siphoning data on CPU and RAM and also all of the network connections and just pumping them into a visual tool in a web browser which allowed you to see all the connections based on the colour and based on the size, you could see a lot of information all in one place and what we learned from this is that very simple visualisations rather can actually be very powerful so you can get a lot of information in one place just by sort of changing the way something looks and we sort of looked at this and even after being able to visualise something well we thought what if we could flip this on its head maybe and actually put input back through a visualisation so we started looking at the problems that exist in the cloud today so how do people visually interact with the cloud at the moment well you've got two dashboards, you've got the AWS dashboard and you've got the OpenStack dashboard and both of them sort of display all the data in a tabular form which for AWS because of it's got this static topology view for all of its users means that that sort of makes sense you've only got a fixed amount of data to display for certain options and you've only got a fixed number of topologies that you can choose from but having played with Quantum we realised that you've got this flexibility that exists inside OpenStack which can't be utilised by these sort of tabular views so having a user be able to create advanced topologies and very complex topologies just couldn't be done through Horizon especially when we started developing this in Stable Folsom so we started designing two tools with one concept and that was to try and make OpenStack easier and a bit more friendly to the user so we built two tools Curvature, our new visual, new age, shiny front end and Denabi, a tool that allows you to wrap these containers into blueprints and you'll hear a bit more about that later so what I'm going to do now is I'm going to pass you over to Brad who's going to sort of go over a lot more about Curvature and you'll see a lot more on this interactivity the logical side of things where you can build up these topologies and also you'll see with the extension of Denabi we've actually made it a lot more adaptable so as these new versions of OpenStack come along you'll be able to build new tools in like things like load balancer as a service and also hopefully firewall and maybe a few more OK great so yeah we're trying to make OpenStack easier to use from a front end point of view in terms of actually deploying so that's quite loud there we go so what we tried to keep in mind when we were building this tool is how you actually work now so for me whenever I'm thinking about deploying whether it's virtual machines or actually on bare metal I kind of draw it out with a little diagram and this is very crude but we wanted to keep this in mind when we were orchestrating like through Curvature so let's jump straight into a demo and I'm just going to show you exactly what Curvature looks like and then we're going to try and do a live deployment and here we go this is what Curvature looks like when we first log in so you can see we're actually visualising the network topology in a graph which is much easier to understand and we'll go through all those different node types in a second but the way you interact with Curvature is we have this tools tab up here so we can see we've got a link tool and that's how we define the networking we connect different nodes together delete tools so we can mark nodes for removing from your OpenStack deployment then we have this images tab which is a list of all of your images from Glance on your OpenStack deployment and you can just drag those nodes on so that they're ready for deployment the networks tab so this is where all of your layer 2 and layer 3 quantum components are and as Sam mentioned it's going to be really simple we interact with OpenStack just by the REST API so as things like the firewall as a service load balancer as a service come in we can just add nodes on there drag those components on and put them into your deployment we have containers which is part of the NARBE and we're going to talk about that a little bit later and volumes which is a list of all of your volumes from Cynder so in terms of what you can see with the nodes this big world icon represents your public or your external network then we have some routers networks represented by a cloud and you can see these colours around the networks and we use that to help visualise what virtual machines are running actually inside a network and this is particularly useful so we can see this virtual machine here has two nicks, one in each network so it's just another way of representing that and you can see as we click we've also got a whole load of data displaying the IP addresses and lots more information about the different types of nodes so let's try and actually do a deployment through this so if we log out you'll see this screen which you're probably very familiar with if you've used Horizon so we're just going to log in with our Keystone credentials and that's really key actually so the configuration for this tool is you only need to know about your Keystone endpoint IP and then from that we can get the service catalogue calculate all of the other endpoints and that's the only configuration you need to actually get this up and running so we're presented with this blank project here with just an external network so we're going to use that crude example of just two virtual machines inside a network connected to a router, connected to the external network and we're going to try and deploy that now so really simple we just grab all of those components and we drag them onto the graph so if we start with the network we're going to drag the network node on and we're going to be presented with a dialogue where we can add a name for that network and we just set a random CIDR for the first subnet in that network and that's popped onto the graph so now we're going to drag on a couple of images because we want to create some virtual machines so we're just going to use the Sirus image and then we're going to select our link tool and we're going to tap on both of those virtual machines and then the network and you'll see that those virtual machines pop in and it moves around and it's nice and it's shiny and everyone likes a bit of that so now we're going to just the final component we need is a router so we just drag a router on and again we use the link tool to connect those components together and I think it's just worth pointing out how easy this tool is to use so our dev stack that we're running on broke five minutes before the presentation and we lost all of our tests like things that we could show you but we really managed to quickly, rapidly build this out using this tool so that was good so everything's blue at the moment and that represents the undployed state in terms of open stack so this is our design stage and we're going to use the delete tool to remove or change any of those nodes we can but we're going to just go ahead and hit deploy and what that's going to do is it's going to make all of those rest calls to open stack and so the virtual machines are orange because they're in a build state and we're constantly getting information back from open stack so we've always got the latest information and the network and the router should be active and there we go those virtual machines are now active as well this is running grizzly yeah and so yeah like I say as things like the firewall as a service and load balance so we can add those components in so now that's all up and running we can do anything that we would normally do so we might want to associate some floating IPs and the way we deal with that is we double click the external network and we can add some floating IPs from that allocation pool and so there's a new floating IP that's just ready to be used and we can just click on any virtual machine that's up and running and we'll be given a list of those floating IPs that we can access and then we can hit associate and there we go straight away that's hit open stack and associated that floating IP so we have a lot of other features as well like to do with security and security groups and key pairs and we're aiming for full kind of feature parity with a bit more added as well to horizon which is coming soon so we're going to just if we can switch back to the slides we'll just say a quick mention about what we've learnt from doing this so the first thing like I said it's shiny and it's really easy to use and everyone loves that so that's been really useful and it kind of takes away some of the mystery of using quantum so we don't actually need to worry about what the interfaces are doing and what the gateways are we need to attach because for a first time user you're complex but we can still take advantage of all these really cool software to find networking components in quantum so that's really good now one thing that we've kind of found was we can build these really complex network topologies in a nice visual way and it would be great if we could save them and use them again so that's why we've built Danabe and we're going to talk about that a bit more now yeah sure so we actually make all of those REST calls ourselves so we bring up networks, routers, VMs it doesn't matter how you drag them on or anything like that we do the deployment across the whole graph yeah at the moment it is yeah so we'll just talk a bit about Danabe thanks Brad so as Brad said once we had this tool and we were giving it to users and seeing how they were playing with it we were finding that people were great they were building these complex virtual network topologies but then you found that perhaps you wouldn't save some of these topologies to use later so we started this is a screenshot of a very very early version of curvature and we had this idea that you could save these topologies you'd just click a button and it would just read this entire graph that you'd built and save it on a back end and you could get to it later but what we were finding people were using these things for was instead of saving an entire network design they might design individual little components that you might want to reuse as part of larger applications so it was at that point that our manager at Cisco, Debo Dutter started talking to us about a proposal he put forward at the Essex Summit a few years ago called Danabe and the idea behind Danabe is that it would define these virtual application, virtual network topologies as containers that would contain either routers, networks, virtual machines any kind of standard open stack node but also containers themselves so this idea that you could build out something complex like a web server stack with low balance databases or application servers connected to web servers but you could build these components as individual containers and connect those together building out all these individual nodes and connecting those and the way that we connect these containers together is using a system that we call endpoints so when you design say maybe a low balance database service container you might have several virtual machines running a database all under the same CIDR of a single network and then you might have your low balance virtual machines part of that as well and you want your low balance of virtual machine that anyone outside the container hits first before it talks to anything else and so that would be your endpoint it's not dependent on curvature in any way it's a completely separate service that runs on its own little web server all interaction with it is done via REST API so we've built it to work great with curvature via REST but you can also just hit it natively using its REST REST template system so the best way to show you how this works is to demonstrate to you how we've integrated this with curvature so I'll just pass over to Jack and he'll walk you through some of that So yeah as you remember from Brad's demo we've got the containers tab up here and that's blank at the minute but what it would include is a list of blueprints from Denarbe that we can deploy so let's go ahead and create one so if we start with a very simple container you can see we've got all the same tools available on the main graph so we can go to the images tab and drag a couple of images on and we can go to the network we can drag a network on and save that and if we go back to the tools we can network this in the same way that we would on the main graph and we do have an extra tool here so as John mentioned we can mark things as an endpoint and that will expose that component on the outside of the container and mark that network as an endpoint and get this container saved so let's call that bottom layer so as you can see the bottom layer container has shown up in our list of containers that are ready for deployment but let's not do that just yet let's explore a more complex container structure so I think as John mentioned you can have containers in containers so if we go over to the containers toolbar we can have say two instances of the bottom layer container and you can see the endpoint there exposed on the outside and if we drag a router on we can get those networks and if we wanted to connect this to the Xnet we'd want to set that network as an endpoint so let's get that saved as top layer so there we go so all that's left to do is try and deploy this so if we drag that on again just as before in the container build you can see that the router is exposed on the outside we can connect that to the Xnet and hit deploy so just as any other component the blue indicates that it's undeployed and what we've done now is by REST API we've asked Denarbey for one instance of this container to be deployed and Denarbey's handling all the deployment logic there so if you run Denarbey without Kermiture you still get that feature it's gone black to indicate that it's up so if we double click it we can take a look inside it's exactly as we designed it we can drill further down we could click on the nodes to get networking information and the CRDRs that the networks ended up getting and yeah so that's that's how we've integrated Denarbey with Kermiture so if we could bring the demo back so how do Denarbey and Kermiture fit in with your typical OpenStack deployment so this is the topology of a typical OpenStack deployment as it looks today and if we go next this is how it looks with Denarbey and Kermiture so again it's important to highlight here that there is absolutely no binding between these two components you can run Denarbey without Kermiture you can run Kermiture without Denarbey and it will automatically detect that and strip the relevant UI elements out and we are by no means done with these components either with Kermiture we want to add the ability to save an entire topology so that would be useful for migrations and other such applications for Denarbey we want to formalise a way to modify live containers so that you can change one container and have that propagate out across the network and we want to add the metadata service to both so that we can start to have some more intelligent containers and say you know configure web servers and databases on deployment so yeah in summary we have Kermiture which is network visualisation and provisioning tool we have Denarbey which is our application container service and we are going to be going open source with both so I wish we had a little bit more detail on that but all we can say at the moment is that that process is underway maybe weeks, maybe a couple of months but we are definitely open sourcing at this point so yeah at this point we would like to open up to any questions yeah that is a conversation that actually we would be very keen to have with Mr Hurley sitting over there up until now this has been a very internal project to Cisco so this is the first time we have had a chance to show it to the wider community and the feedback we have had to it is absolutely fantastic we are seeing there is obviously a need out there for this much more kind of tactical way to interact and if there is a way we can get it out there and get it integrated with Horizon then that is definitely a conversation we would like to have both of these components are actually run on top of Ruby on Rails which you can probably shun us as heathens for that it does break with the pipeline yes definitely when we started with this project actually we came in to Cisco Systems in July last year not knowing anything about doing web apps so for us we sort of jumped in and our manager actually pushed us in the general direction as Rails as it was sort of a starting point for us so most of the logic for curvature is in the JavaScript HTML5 and the SVG rendering that we do so most of that is up there we just use Rails as a pass through to open stack in that instance so curvature is completely stateless so it's all happening so theoretically all the curvature stuff would be all the power of that really is in the JavaScript so yes it was just for demoing just hit random that way we didn't hit into overlapping IPs and things like that it was just a nice convenience feature yeah it was it was when we first started working with it we didn't have floating IPs turned on in quantum so we'd end up with constantly getting networks that ended up overlapping and we couldn't be bothered to keep writing out the same IP address again and again and again so yes definitely so what we're hoping to do actually in future versions is hopefully to hook in and get some actual WebSocket stuff going so if anyone actually tries to use a different dashboard or the CLI any changes will actually get pushed back up to the browser even without a refresh so that's the sort of thing we're heading for go ahead aha okay yeah definitely if you mind if I jump in go ahead Dan Arby we first started developing it actually like John said when we had this ability to save these templates and we saw that was really useful and decided to sort of break it out and the main focus of it at the moment is purely on the ability to save the topology so at the moment there's no ability to actually configure the VMs so it would be definitely something worth looking actually into is whether we could integrate with heat and actually get that up into the front end as well so maybe get some ideas shared between us there but the ability of curvature is such that we should be able to plug in components like heat and we've been talking to potentially plug in other components that we've seen around as well so yes yeah we can definitely get some of that more information out there definitely we want to start conversation with the community about this so we really want to get more involved yeah I mean yeah absolutely as future functionality that's definitely the kind of thing that you could extend all this to do we've tried to design it we've designed it kind of with open source in mind from the very beginning so we've tried to make it as easy to add in new functionality like that or strip out functionality you don't need or anything like that right now obviously it's all fully just concentrating on interacting on the API layer getting all this information building your topology but yeah if that's the kind of thing that users for them absolutely it doesn't but that's something we are going to add we've actually we've got the ability to catch any of the errors that actually come back from OpenStack so we've been using those to actually manage the deployment as it goes along if it would deny be itself if it encounters actually any errors when it's deploying a container it will roll those back so it'll completely undeploy everything that's deployed up to that point so we thought that would be it's sort of almost a transactional action to deploy a container on Denarvys side on Curvitch's side of things rather if it encounters an error halfway through deployment everything on the graph will actually remain in the state that it was before deployment apart from the things that have actually gone up successfully yeah so if you wanted to you could then go back and delete mark some nodes for deletion re-hit deploy and it will do those deletes first wait for those to come down and bring up whatever you had before any other questions yep it absolutely does so that first when we first loaded up the first screen you saw on the when we switch from the slides is all information that's been loaded in live from the APIs on a dev stack that's running on our machine here so you can as I think Sam mentioned or Brad mentioned the only configuration option we have when you install Curvitcher is the IP address of your keystone service so you boot it up you log in through keystone you get the service catalogue we get the end points of all the appropriate APIs and we read in that information every time you refresh the page and it learns your whole topology and it draws it so you could point this at any open stack deployment running the appropriate services and see a Curvitcherised graph of what you've got going on well yeah I mean you could you want to start boot up Verizon like spin up a VM I'll do it through Verizon that's a bit easier thanks Gabe so so you want to jump into the project but yeah we when we actually first started playing with open stack it was falsam so we started playing around with Quantum as soon as it came in and we actually started playing around with all the layer 3 stuff immediately so we didn't have the support in Horizon for things like the routers which is why we started actually developing the ability to do it through Curvitcher it was much easier that way rather than ending up having to make like 16 calls to the CLI to remove three routers that you'd spun up by accident so yeah we just deployed one and now there's three in that network so great cool that worked yeah yeah yeah we're getting there definitely it's in the works and we cannot wait for you guys to actually be able to play with it and yes that's up to the community there you go yes yes yeah absolutely yeah definitely I think one of the reasons that we started kind of building our own topology saving structure when we were doing this is simplicity was key number one we just needed to be doing the kind of stuff you've seen here so we didn't need some of the extra functionality that's in there in heat but also at the time I don't think there was Quantum support in heat if I'm right there so yeah so we needed to jump straight to the Quantum stuff so that was the main reason we went down that road so something yeah definitely something actually we jumped into a few of the heat discussions and something we've been looking at is actually the ability to move towards Tosca for the actual structure to be sent around and that seems to be in the same direction as he was going to yeah like we say we've kind of been isolated in our own little pod in Cisco for the last few months and this is our chance to kind of open up these conversations and we're really keen to do that great no other questions alright thanks for coming to see our work thank you very much