 Hi guys. So this talk is going to be about billing stack, basically, which is a project done for doing charge back and billing services on kind of like consuming salameter in open stack. So many guys think that like the whole billing kind of thing is kind of like boring. It's not that fun. There is all the auditing, all the all the boring processes you don't usually want to develop like time and time again. But the kind of sad issue with open stack is there is like there isn't any default billing system you can go and use for your charge back or billing services. So these are the URLs for the project at the moment. They're kind of temporary. So we're going to move some of the stuff over to Stackforge to use the open stacks CI stuff and all that. So it'll be kind of like going into the open stack release cycle and trying to release when they do. There is the documentation and read the docs. There is the current home for the different projects. So kind of today is like going just quickly through what is billing stack, what we've done and what we're wanting to do. So we're only two guys at the moment. So it's a pretty small two man army. So there's emails and what we've done and all that. So as I said, there is kind of like different issues with the current billing systems that you can get like which is open source. They're kind of like old style, not really meant for the cloud billing space. They're like no good, I mean, there's no good alternatives that you can get for free that you can download and customize and do what you need with. There's only stuff like J billing, you have a curly, but none of them actually comes with any default integration towards like open stack or salameter. There's also the thing where like the current like what is open source billing systems like J billing, they only release like one one release or one version like every year at most. If you go check out like J billing, you'll see that they have like a version which is from last year sometime and it doesn't come with any integration APIs. There's no like documentation really. There is no help to get unless you pay for it. And it's kind of expensive if you want to buy one as well unless you just want to use the curly, for example, chargeify, which are the two SAS vendors on the online market, I guess. So we started out doing billing stack, which is basically a piece of Python stack software kind of like open stack for billing. So we have like written in using the, I mean, we have the Apache license for the license. So you can like grab the code to whatever you want with it and just be using it. There's interfaces for doing things is very easy to like plug in new stuff because they'll like pay some plugins to just make a change in a config. You're using something else than what's standard. It's very decoupled. So you have like the different services for doing like payments, invoicing, and everything else in the billing space is like you can just rip it out and use your own. And as I tried to point out earlier, it's kind of like we're hoping to be the default billing system for open stack. You can just, if you need to use, just pull it down and use it. So we kind of have like the traveling down the payment lane from when you're pulling some data from Celerometer, wanting to mediate it towards a billing system, wanting to apply some prices on the data that you've been pulling down from Celerometer. You're wanting to take these things which has been rated and actually turned it into an invoice. And then finally, you want to do like, you want to like charge your customers for this, either if you're using some kind of in-house system to do it, like SAP or something, or you can use online payment gateway or something else, like brain tree or speed leap. So this is an overview of what we have like different processes within the billing space until now that we've done what we want to do. And there's like an overview of each process and which component in billing stack is doing it. This is kind of how it looks. So you've got the kind of like open stack or someone else sitting on the top, which is kind of like your source for doing things or the source of the data. So you want to pull the data, mediate it and push it up to some random billing system, which in our terms is billing stack, wanting to apply the rating, which is the radar service, which is then billing stack or something else. You can use the biller to like make invoices. Then there's the collector, which goes out and takes the invoices and collects your money for it or the payments. We have a client or like CLI and language bindings library for interacting with different kinds of billing systems. It doesn't care if you're using billing stack or if you're using a Curly or Chargeify, it's just API layer kind of. So what's really neat is you just tell it the provider that you want to use and it's kind of like the same top level API. So you have the meter service, which is basically collecting all of your data inside of the cloud, like the salameter. It's querying, I mean it's collecting the data and aggregating it, storing it. It's like there. So the mediator is basically taking the like salameter raw data thing and wanting to turn it into something useful basically in terms of financial stuff. So this is then showing the one of the proposed kind of like mediation processes where you're pulling the data from a source, which is salameter or something else. You're taking it into the mediation process or the script whatever you want to use and you're pushing it into billing stack, this kind of scenario. So one guy came up with another idea, which is basically instead of having a mediation process, which like pulls data and push it into the billing system, you have salameter maybe pushing the data for you instead when it's like collecting it. So salameter goes out to some open stack-ish service and says, or it gets like the amounts of compute hours that's been used and it pushes it straight into the billing system. So you can have like almost like live billing kind of or live stats for billing, which is pretty cool. It's like what Amazon just started doing I think a few months back. The cool thing about the whole billing, the previous slide, it has the factorial stuff. So basically the destination, if you're using the client library, you can use whatever billing system is supported there or you can write your own plugin. So if you have something in-house billing system, you can use that. If you have something else you need to pull data from like some legacy system or something that you wish to use billing stack for, you can use a source plugin to pull the data from. So this is kind of like the billing stack core service. It has the notion of a multi-tenant thing going on with merchants. So you have like, if you have different companies or organizations for the new company and you want some of them to be able to build kind of like their own thing, you can just make them a merchant or you can have like one globally for everybody. It has products, which is like instance for example or like disk usage or anything else. It uses a plan to kind of like group together the products when using plan items, which is pointing to a product that we were wanting to build. So a plan would be like compute for example, where you would have like some storage on the instance, some network traffic, the CPU hours that it's spending. We have a thing called subscriptions, which is, if you're familiar with like other kinds of billing systems like this, it's kind of like the link which links the plan, the customer and the rating data. Like it's kind of like the link to the other system we're getting the data from. So we have like the mediator. We have like billing. The idea is to have like a billing policy so you can say like this thing should be billed every hour or something. It's kind of in a draft at the moment. So basically the rating service or the radar is taking the incoming data from something which you're pushing into the billing system and applying prices to it and just storing it in a database. It's based on the plans which has the prices basically. There is the billing service which will basically take the billing rules that you have which can be like discounts and other various things like this. Discounts, add-ons, anything else that you want to do before creating the invoice. So it takes, it has like the invoice with a lot of invoice lines. So you have like for example a day in a week which can be like an invoice line. This too has like policies for when you should be creating the invoice. Basically it's the idea behind it. It's doing billing basically per customer or the invoicing. It's creating the invoice. It's doing like the applying the billing rules to the usage thing. And taxes and when it's due and the discounts everything like this. Then you're wanting to charge for something that a guy has been using so if your user is like consuming tons of computer hours you want to build this, get paid for it. There's a service for that as well. So this is storing the payment gateways which can be right now is targeting targeted system to build the stuff from. I mean to take the payments from. It's creating transactions storing towards the payment gateway. So it does like I'm going to charge you for like 50 bucks and it tries to do this and it stores it in the database if it succeeded or not. That's then the amount is then removed from the invoice like that you have like invoice which is X amounts of dollars and you're trying to charge the guy for it. There is various payment methods also. So you can have like a customer can have like a visa card, credit card. It can be just to place a transaction in some other system if you're using SAP to take charge towards the department and the company. That's what that's doing basically. So we have like a small demo video showing the UI which is basically written in using AngularJS familiar with that. It's a JavaScript library which will basically use the REST API of billing stack for administration. We also have we're planning to do like a horizon integration so users can go and see how much they've used of an instance. You can control the payment methods and so on as well. That's basically creating a merchant. So you're basically like signing up into billing stack. Then he's logging in. There you see the view that we come into when you're signing in. He's making a product which is in this case some storage stuff. So you can do like a plan which is just filling in some text and linking it to the product and some price. So there you're doing like the linking from the plan and you're making the price stuff and how much you're going to charge for a product. We like adding some other stuff. You can do like volume based pricing and you have fixed pricing and there is the other one as well. So you can define like if somebody is using a range of something from the salameter and it's between the given range will apply different prices. So this is basically all using the REST API which is running in the background somewhere. The user doesn't know it basically or it is. You're adding a customer which is basically a tenant in open stack. So you make like a customer and you have the subscription which is going to be linking the customer inside of billing stack to the tenant ID. There's the credit cards going in. So at the moment we're not storing the payment card. I mean the credit card information because of different compliances. So we're just pushing it to some payment gateway that you want to use. Because if not you'd need to go for the whole audit stuff and all that. We're kind of working on that. Sorry. So the question was if you can use billing stack, like if you can have like hosted applications use billing stack to bill their stuff. Was it right? Yeah you can. So you can just let it sign up for as a new merchant as his own merchant and you can use then it's totally isolated from the other stuff you know. So what was I wanting to have like we haven't done it yet. We're wanting to have like the notion of like a reseller for a merchant. So you can have other guys reselling your stuff. So the lights went off. Pretty funny. So basically what I have. So I want to say thanks to the guys that's been helping this far. We have some very cool guys from other companies wanting to help and which has been helping until now. So any questions? Yeah. So you have the yeah. So the question is how do we map the whole product thing to something in salameter. So you have like the product name. That's going to be the same as like CPRs inside of I mean inside of salameter. So it knows how to take the when you're setting sending the data from salameter over, you basically have the name of the thing that we're going to build, which is the name of the product. Had at some guys from television yesterday who was wanting to help out and some other guys. So a lot of this is kind of like in the draft phase. So we have I didn't mention this, but we have a thing called the payment gateway plugins, which is basically a plugin API that you can like your right your own class for something. And then you basically you define the methods that you need, which is the same as the base class. And then billing stack just knows how to do like create transaction create account create credit card. Yeah, it's like yeah, you can even use stuff like Spreeley. So if you like if we like make Spreeley interface, like a plugin, then you have like support for, I don't know, like hundreds of different payment gateways, I think. So yeah, so basically when you're so when a merchant likes makes a new payment gateway, it has its own configuration. So it's totally isolated from the other merchants. And when you do like add a customer, it's going out to the payment gateway and making it a customer or new account. So but we're not adding the not adding the customer before you have added like a payment method, because it wouldn't make sense. What was your question again? So you're wondering if you can do like just show the cost and I'll actually bill it. Yeah, you can use you can do like create the invoice or you can replace any of the components with whatever you want, basically. So it's just a stack of different pieces that you can like mix and fix together. Yeah, we we have like many different use cases, like hosting guys inside of companies, which just wants like I had a use case of my previous employer, we just wanted to have like, you have used this much, we need to charge you for this. And that's basically what they needed. So you don't need to use the whole stack. I'm just gonna you had a question at the moment it is, but you can like, you can just simple script, for example, which is just queries, something in Keystone, just makes a customer inside of the given merchant and then makes a subscription and you're done. Or you can we're wanting to do like a thing within Horizon. So basically when like, or anywhere else, when somebody says like signs up, you already have all of this in the billing system and it's just there. So how do you mean like, if you can administrator, I mean, administer the whole thing by a horizon or it's a bit witchy, you know, because some people want to use don't want to use billing stack, they want to use something else. So we have the whole factor of stuff. And basically what it allows you to do, you can make like one generic plug-in for Horizon and it can use this client to just communicate with the billing stack or the curly. So the features are going to be different. So we want to narrow the scope for Horizon to what's needed, like how much you've used, how much credits you have left and that kind of stuff. So there was a question from there. Yeah, I'll do the guy in the back next. What was your question? Yeah. So you're basically wondering if like, that the tenant shouldn't be able to create instances before they've paid. Yeah, we have the stuff on the roadmap kind of. So yeah, but it's definitely a thing that some companies don't want to guys wondering about and just like making 20 instances before they've paid. Or if you want to have like workflow, maybe like if a guy signs up, the boss needs to go and approve like X amounts of credit per month. That might be a use case. You had a question? We haven't come that far, but we have. So we have like another use case as well, which is your tenant has like a credit card, but the payments isn't going through. So what do you do then with all the stuff that is running? If it's a service provider, or if it's within a company, you have the same thing. Like you might have like, say you want to give each user like X amounts of credit, credits per month, like US dollars. What happens when you've actually run out of credit, you just shut down and delete his account or something, or do you like given an email and say, you need to do something with this? If not, we'll shut down your instances within three days or something. You have like Rackspace does this. And I think every other major vendor as well, they're doing like, if you use up your, if you don't pay or use up your credit, they'll send you an email telling you to go in and fix your credit card. And if you don't, you have like, I think it's seven or something days and they'll just shut down your stuff and deactivate your account basically. Yeah. There's like different use cases. Some people want to just shut down everything and disable the account. Somebody else wants to do something else. So it's, we need to come up with a way that I think those, the different things, like some kind of policy maybe like payment policy, like if you don't pay, what do we do? Yeah, that's no, we don't have a thing for that yet. But it'll definitely be a case. Yeah. So we have an API. So you can use like, I mean, you can either possibly make the payment service go ahead and check towards the payment gateway. Yeah. Yeah. Or you can do like, so if it supports like, if the payment gateway does like push notifications, you can configure that and have it push into the API. Or you can have the, I mean, the payment service go ahead and like, what's going on?