<div class="gmail_extra">my comments below</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 22, 2012 at 10:32 PM, Brian Schott <span dir="ltr"><<a href="mailto:brian.schott@nimbisservices.com" target="_blank">brian.schott@nimbisservices.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Have you started a blueprint and/or Etherpad? We should do that.<div><br></div><div>
Couple of comments:</div><div><br></div><div>1. I had an idea for naming the metering service after Nipper, the famous RCA dog :-)</div><div><a href="http://en.wikipedia.org/wiki/Nipper" target="_blank">http://en.wikipedia.org/wiki/Nipper</a></div>
<div><br></div><div>2. A common metering service that listens on Rabbit/ZeroMQ bus for registering events is a good idea, but we need to document some use case scenarios to really nail down the architecture. Who signals the metering service? The API service or nova, quantum, swift, glance, volume? I'd argue that the individual services need to hook into the metering service and that you can't just monitor the message bus for calls from the API service.</div>
</div></blockquote><div><br></div><div>Each service should signal the bus, these are the different exchanges/queues</div><div><br></div><div>The metering service should subscribe to whatever it wants to be notified, then react with custom implementation for each event. I identify a template here:</div>
<div><br></div><div>1. persist the event (useful for accounting)</div><div>2. mediate and notify the monitoring tool</div><div>3. mediate and notify the billing tool</div><div>4. ... (whatever)</div><div><br></div><div>Consider than extra billable services like platformlayer (from Justin) should feed the bus, and the metering should be aware of them in the same fashion.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>- A user launches a flavor A instance of image X through the API service. When nova receives a run_instances request, nova signals nipper with the instance details, the flavor details, and image details. As the instance transitions through its states (pending, starting, running), nova signals nipper on each state change. Nipper will need to have an immutable copy of the current flavor, image, and instance information in case an administrator changes/deletes this information in the future. You want a bill to reflect what resources were consumed, not what the flavor describes when when the bill is generated.</div>
</div></blockquote><div><br></div><div>My vision is that billable systems knows nothing about cloud, they only know how to bill items. So extra info is for accounting and monitoring. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div> </div><div><br></div><div>- From within the instance, a user issues a "shutdown -h" command. Nova signals nipper that the state has changed to "shutting down", and then to "stopped" or "terminated" depending on nova's config.</div>
</div></blockquote><div><br></div><div> OK</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>- A user creates a volume of flavor X of size N. (won't the volume service have different flavor of volumes like SSD, sparse, raid-x, ...?). The volume service signals nipper that the volume has been created. Nipper needs to have an immutable copy of the current volume flavor, utilization, and size.</div>
</div></blockquote><div><br></div><div>I think metering service, is only a dispatcher of asynchronous events to the specific systems. I mean metering is behind the firewall and billing, accounting, monitoring should not. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>- A user allocates a public IP address. Quantum....</div><div><br>
</div><div>2. A separate "billing" service should have a "pricing" plugin similar to nova's scheduler. This should handle generating "quotes" for a given flavor, image, volume, network, combination and generate invoices as you describe.</div>
</div></blockquote><div><br></div><div>Totally agree, this is part of the billing system: for example Dough. Zuora, whatever </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br></div><div>3. I'd steer away from mandating implementation technologies in the architecture. MongoDB is fine, but others here would prefer to make their own deployment choices.</div></div></blockquote><div>
<br></div><div>Agree, I have put them because I am working on a POC using these technologies</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div>Brian</div></div></blockquote><div><br></div><div>Thanks Brian! I like your vision! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div><div><div>
<div><div style="font-size:12px">-------------------------------------------------</div><div style="font-size:12px">Brian Schott, CTO</div><div style="font-size:12px">Nimbis Services, Inc.</div><div style="font-size:12px">
<a href="mailto:brian.schott@nimbisservices.com" target="_blank">brian.schott@nimbisservices.com</a></div><div style="font-size:12px">ph: <a href="tel:443-274-6064" value="+14432746064" target="_blank">443-274-6064</a> fx: <a href="tel:443-274-6060" value="+14432746060" target="_blank">443-274-6060</a></div>
</div><div><br></div><br>
</div>
<br><div><div><div><div>On Apr 22, 2012, at 2:50 PM, Luis Gervaso wrote:</div><br></div></div><blockquote type="cite"><div><div>Hi,<div><br></div><div>I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support:</div>
<div><br></div><div>1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel)</div>
<div><br></div><div>2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion)</div><div><br></div><div>3a. The monitoring system can pull/push MongoDB</div>
<div><br></div><div>3b. The billing system can pull to create invoices </div><div><br></div><div>4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel)</div><div><br></div>
<div>
This is to receive your feedback. So please, critics are welcome!</div><div><br></div><div>Cheers!<br clear="all"><div><br></div>-- <br>-------------------------------------------<br>Luis Alberto Gervaso Martin<div>Woorea Solutions, S.L<br>
CEO & CTO<br>mobile: <a href="tel:%28%2B34%29%20627983344" value="+34627983344" target="_blank">(+34) 627983344</a><br><a href="mailto:luis.gervaso@gmail.com" target="_blank">luis@</a><a href="http://woorea.es/" target="_blank">woorea.es</a></div>
<br>
</div><br></div></div><div>
_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></blockquote></div><br></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-------------------------------------------<br>Luis Alberto Gervaso Martin<div>Woorea Solutions, S.L<br>CEO & CTO<br>
mobile: <a href="tel:%28%2B34%29%20627983344" value="+34627983344" target="_blank">(+34) 627983344</a><br><a href="mailto:luis.gervaso@gmail.com" target="_blank">luis@</a><a href="http://woorea.es/" target="_blank">woorea.es</a></div>
<br>
</div>