<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Dan (et all),<br><br></div>you know that the customers are always unsatisfied....:-(<br><br></div>The first important stuff would be to have in place the metrics of consumption of the<br></div>resources some hoster &quot;sell&quot; to a customer. So usage metrics on<br></div>CPU / RAM /  DISK / Network (over provisioned or not is another story)<br></div>There is an aspect on actual usage versus provisioned usage.<br></div>{vm provisioned 10 GB of RAM bus os+app uses just 5 GB of them etc)<br></div>But let&#39;s keep it simple.<br><br></div>Should we have the usage reference then a GUI that the can define <br></div>the cost plans, would be ideal. A way to query if possible that<br></div>database, would ease existing ERPs and invoicing software to <br></div>produce / send invoices. This is for mostly post paid use cases.<br><br></div>For prepaid situations, there must be some regular accounting that<br></div>will stop the service through our current API. It sounds a bit scaring to<br></div>actually shutdown the provisioned vm. So at least on first step stop the<br></div>networking ....<br></div>I guess that the base is to create a separate database that will keep the<br></div>consumed metrics, so that customers could actually use it to <br></div>enforce some business logic. (as explained above).<br></div>Should there be a minimal gui that could a small hoster create<br></div>his owns plans and perhaps issue some &quot;invoice&quot; would be ideal.<br></div>Since there are a number of open source billing systems out there,<br></div>perhaps the integration is not that complicated. A second thought would<br></div>be to extend the data ware house gui to create the &quot;invoice&quot; outputs<br></div>as most of the usage info is there.<br></div>I know that ovirt is supposed to be a virtualization solution and not<br></div>a full monty billing system. <br><br></div>Thanks for reading so far.<br><br></div>Nikos<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Nikos<br><br>########################################3<br>Zaharioudakis Nikos, RHC{A,DS,E,VA,X,I}, VCP(4,5},VCI, Mentor VCI, Zimbra Instructor<br><a href="https://www.redhat.com/wapps/training/certification/verify.html?certNumber=100-001-262&amp;isSearch=False&amp;verify=Verify" target="_blank">https://www.redhat.com/wapps/training/certification/verify.html?certNumber=100-001-262&amp;isSearch=False&amp;verify=Verify</a><br>Public  Calendar : <a href="https://www.google.com/calendar/embed?src=nzahar%40gmail.com&amp;ctz=Europe/Athens" target="_blank">https://www.google.com/calendar/embed?src=nzahar%40gmail.com&amp;ctz=Europe/Athens</a><br>+30 694 720 40 63<br><a href="http://zimbra.wikidot.com/zimbra-installations-in-greece" target="_blank">http://zimbra.wikidot.com/zimbra-installations-in-greece</a></div></div>
<br><div class="gmail_quote">2014-11-20 15:08 GMT+02:00 Dan Kenigsberg <span dir="ltr">&lt;<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Nov 20, 2014 at 02:20:46PM +0200, Nikos Zaharioudakis wrote:<br>
&gt; Brilliant,<br>
&gt;<br>
&gt; Thanks for the info gents<br>
&gt; Looking forward for 3.6 then :-)<br>
<br>
</span>Just waiting may not be enough: I&#39;d love to understand what are the<br>
metrics you&#39;d like to use for billing.<br>
<br>
I mentioned cummulative values of network, storage, and cpu per VM. Can<br>
you consider anything else? The latter two are begging for an RFE to be<br>
open, as well as the report-centric RFE requested by Shirly.<br>
</blockquote></div><br></div>