 Hey everybody good afternoon. Thank you for joining us. I'm Sanjay Mishra with Taligent and I want to take a few minutes of your time and talk about Open Book, our billing solution for OpenStack and talk you through some of the basic functionality. As I go through the solution I'm going to focus on the two aspects. I'm actually going to walk through the two UIs that we have. We have an admin UI which is targeted towards the service provider administrator or the private cloud admin and that's the UI that's used to set up rate plans to to edit details of customers and resellers and so on and look at invoice history and and do some analytics on the data that's being collected and then with the time remaining for the second part of the demo I'd like to focus on the customer view into the interface and so we have a customer UI that lets the end user come in and look at usage and financials by their project and then also focus on a self-registration component where somebody can actually onboard and self-register and have a project created and and get going with OpenStack. So let me walk in let me log in to the admin UI and actually before I do that let me say a quick prayer to the God of Life demos. I think everyone's happy today and we should be good but just in case. So what I'm going to do is just start with what the end product is and start with that as the focus. What is an invoice that comes out of OpenBook? What does it look like? So for a little bit of background we we have a deep and I want to say almost exclusive focus at the moment on OpenStack. We integrate with Solometer. We also add initial integration and setup time connect with the other APIs so Keystone, Cinder, Volume, I mean Cinder, Nova, Neutron and so on and so when we first integrate into an OpenStack environment we build a snapshot of what the tenants and their infrastructure are at that point in time and then we switch over to Solometer and going entirely through Solometer we get a history of what provisioning activity has occurred, what state change activity has occurred and then obviously metrics and utilization data so then we can use that to build an invoice and or a bill that we present to the customer. So just talking through this at a high level in terms of producing an invoice for a customer pretty much anything that's available to you from Solometer or that is able to be provisioned into an OpenStack environment is available for you to bill on. Looking at this sample invoice so we've got categories of infrastructure, instances, instant types, what the rate is, what the billing interval is that I want to charge on, what state the machine is in and so when I after this as I pull up a sample rate plan and show you how that's configured you have an option of it just exists or it's powered on or even actually in the context of a VDI integration that we have is it in use is somebody actually logged into the machine and you can combine these things in a way that makes most sense from a billing perspective from your side and then obviously we're keeping track of the actual utilization on a per minute basis so as a machine gets powered on powered off we're monitoring that activity and then building utilization intervals that that we can bill based on. Scrolling further down so usage-based charges you have the ability to collect any metric that comes from Solometer. Most common use cases obviously are network traffic, network outgoing bytes, storage container size and so on and so being able to take all of those and being able to apply a charge to that and then finally the volume example shows being able to bill based on an attribute of an entity so in this case as part of our regular synchronization we're collecting a subset of attributes that make sense from a billing perspective and in the case of volumes size and type is probably the most likely set of candidates and so if you have a scenario where you've got multiple types of storage available you have a different rate for SSD versus just spindle based storage we can capture both those metrics and and and take a look at the size attribute apply a rate to it and and you have a charge. So that's a high-level overview of what the invoice looks like. Let me briefly touch on setting up a rate plan and just add a little bit of detail to what the specifics of that are. So as I was mentioning rate plans you have the option of having multiple rate plans within the system. You can assign rate plans directly to customers or you can configure rate plans as defaults by some combination of rules. So for example you can have rate plans that apply to all customers. There's a default rate plan for all customers. You can use name pattern matching to assign rate plans or you can just come through and explicitly assign a rate plan to a customer and have a one-off billing or a rating scenario in that case. We also have full support for resellers. I'll talk about that in just a minute and so you have rate plans that apply to resellers. You have rate plans that apply to customers and this is how you would configure it. We have full currency conversion support. So the way that works is there's a currency that's associated with the rate plan and then when a reseller or a customer is configured there's a currency that's associated with them. So at the time that we produce the invoice we perform the calculation in the rate plan currency and then we convert that to the customer currency and present the invoice to them in their local currency. Rate plans have different periods of validity so you can actually configure a rate plan to be active at some point in the future and when that time occurs then the current rate plan gets expired and the new rate plan takes effect and the new rates are what are used for the billing. Feature-based charges as I was showing in the cases of instances and so on so being able to take any type of entity that exists within the open stack environment and being able to take a look at its state and its billable interval and being able to associate a charge with that this is where you would set that up. So if you think of it at the highest level I just want to look at my entities I want to see do they exist are they powered on and then associate a charge with that. So again in the case of instances we're regularly synchronizing what the what the instance flavors are in the open stack environment and making them available for you to be able to attach a charge to that. Attribute-based billing is going down to another level of detail so a common use case in this scenario is if the instance is running Windows then I want to have an additional charge of X per hour to cover the licensing fee. So in this case we're looking at the open stack instance config attribute image and have an additional charge of 0.05 cents per hour if the machine is running Windows. Usage-based charges as you would expect these are the actual metered consumption and we support the ability to have either a simple calculation so we just go through take the salameter data that's being received added up over the period of time apply a number to it and there's a charge or we can also do tiered billing. So in this case the scenario is that we're looking at the total metric that that we have at the end of the billing period we find the tier at which it matches and then calculate a charge based on that. The other option with tiered billing is being able to slice it up so you can say take the total measurement split it up into the actual amounts over these tiers calculate a composite charge that consists of the value per tier and then present that as the final charge. Event based charge is not very common but you could have scenarios where say from a support perspective or something if a certain type of instance gets provisioned and you want to have a specific charge associated with that then you have the ability to take the event activity that's occurring and attach charge to that. So that's sort of the high level of setting up a rate plan before so as part of closing this out let me just walk through resellers and customer self-service. We have a full a fully end tiered reseller model delegated administration we have users associated with resellers and so when somebody logs in they see the customers and activity and so on that's specific to their particular environment. Resellers can set up their own rate plans they can charge customers according to whatever scheme makes sense for them. Some of the other components so again you have a choice of choosing how you want you as the cloud as a service provider how you want your resellers to be provisioned and you can either charge them by percentage of what the total billing is or by specific rate plans. We support payment processing so one of the things that can can be configured as part of the reseller configuration is what the PayPal merchant details are and so when a customer self-registers they have the option of choosing whether they want to receive a monthly invoice or want to be built through PayPal and we can collect that detail and actually process payment for them and then a little bit of personalization so we in an HA proxy kind of environment where you might be exposing reseller friendly public URLs we can take that URL and map it into a view that's specific for that reseller so in this case we have this reseller green.ch when the registration page or when the customer portal for that reseller renders we want to display the the resellers logo and so we have this configured here so let me switch over to that as and and just in the four seconds that I have remaining touch on the customer self-registration piece so again this is the branded reseller green.ch page I can come in here self-register once I've self-registered the there's a project that's created for the user the end user can specify their payment details as they wish and so you know say they're configured to pay on a monthly basis through PayPal they can set up a pre-authorization and then for that reseller we process that payment and finally let me just log in as a customer and so now I've gone through the self-registration I have a project in OpenStack and as I'm going through I've received an invoice and I can log in sorry and so as an end user this is my view into the environment we we support a couple of additional things other than just finances here I can look at the details of what the what my invoice is this is a view that's similar to what you saw on the admin UI side but the goal here is to present as much detail to the end user as possible so they can see exactly what they're being built on the basis of some of the other things that we have included in here are extendings are the self-service model so as an end user if I want to request an increase to my quota as I can come in through here we have workflow on the back end of this so that I can request a change and this this request will route to an administrator optionally for approval and once it's been approved it we go through the OpenStack APIs and actually make the change for that particular project and they're up and running and actually I said this was the last thing but I'm gonna put one last thing up here this is something that's just hot off the presses and even I'm not brave enough to actually do a live demo with this so I've taken a screenshot and wanted to present it to you the the detail that you just saw in the customer UI our goal is actually to very soon fold that into horizon so with the notion being there's a single pane of glass that the end user comes to and from that you know we add a financials tab and they can look at what their their invoice history is and then they can request the same quota changes that we just saw or on the other side and I am now two and a half minutes over so I'll stop thank you very much we we have a booth just behind the canonical guys if you'd like more information please stop by and and ask would be happy to talk to you some more about it