<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Courier New;color: #000000;font-size: 10pt;">
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF198104"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Doug Hellmann [doug.hellmann@dreamhost.com]<br>
<b>Sent:</b> Friday, November 16, 2012 8:53 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [nova][ceilometer] model for ceilo/nova interaction going forward<br>
</font><br>
</div>
<div></div>
<div><br>
<br>
<div class="gmail_quote">On Thu, Nov 15, 2012 at 6:58 PM, Sandy Walsh <span dir="ltr">
<<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-size:10pt; font-family:Courier New"><b style="font-family:Tahoma; font-size:small">From:</b><span style="font-family:Tahoma; font-size:small"> Doug Hellmann [<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>]</span><br>
<div style="font-size:16px; font-family:Times New Roman">
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b>Sent:</b> Thursday, November 15, 2012 5:51 PM</font></div>
<div class="im">
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">On Thu, Nov 15, 2012 at 4:04 PM, Sandy Walsh <span dir="ltr">
<<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:</div>
</div>
<div>
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div><br>
</div>
So this should be a Ceilometer notifier, that lives in the Ceilometer code base and is a nova.conf --notification_driver setting for whomever deploys it. This implies there are two ways to get notifications out of Nova:<br>
1. via the Rabbit Notifier with an external Worker/Consumer (preferred for monitoring/usage/billing)<br>
2. via a specific Notifier (like <a href="https://github.com/openstack/nova/blob/master/nova/openstack/common/notifier/log_notifier.py" target="_blank">
https://github.com/openstack/nova/blob/master/nova/openstack/common/notifier/log_notifier.py</a>)<br>
</blockquote>
<div><br>
</div>
<div>> We're talking specifically about values like disk I/O, CPU stats, etc. That data isn't generated as part of</div>
<div>> a notification, that's why we're having to poll for it. What we're looking for is a solution that doesn't involve</div>
<div>> ceilometer importing part of nova's code *in an unsupported way*, as it does now. Some of the options</div>
<div>> presented involve new network-based communication between the existing ceilometer agent and the</div>
<div>> compute agent (RPC or REST, in different directions). None of those is really optimal, because we don't</div>
<div>> want to burden the compute agent with lots of calls asking for stats, either for metering or for monitoring. I</div>
<div>> think the option the ceilometer team is favoring at the moment is making the hypervisor library in nova a</div>
<div>> public API, so we can use it without fear of the API changing in unannounced ways. That would let us keep</div>
<div>> the hypervisor polling in a separate daemon from the hypervisor management. There are details to work out</div>
<div>> about how such a separate library would be implemented.</div>
<div><br>
</div>
</div>
<div>I don't know how some shops would feel about putting an api server on their compute nodes. </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>> It wont' be an API server. We just need the nova team to agree that other projects consume some part of the
<br>
> virtualization library so that the API of that library doesn't change without warning.</div>
<div> <br>
I think my plug-in proposal at the data collection stage would solve that.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-size:10pt; font-family:Courier New">
<div style="font-size:16px; font-family:Times New Roman">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>I'd use the same approach we use everywhere else in OpenStack, make the data collection portion of the hypervisor a plug-in. Each plug-in in the chain can add a new data section to the dictionary sent up for transmission. Out of the box we would send the
basic stuff that is sent today. Other deployments might add some ceilometer/hypervisor specific modules to gather other things.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>> What event is triggering that transmission, though? There's nothing doing it currently.</div>
<div> <br>
Yes, the periodic task does this currently. I wrote about this in another of the integration posts, there is a periodic task that calls down through the virt layers to get data in a hypervisor independent fashion.
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-size:10pt; font-family:Courier New">
<div style="font-size:16px; font-family:Times New Roman">
<div>
<div class="gmail_quote">
<div><br>
</div>
<br>
<div>I was specifically talking about lifecycle notifications, in which case atomic snapshots of state are desired. Regardless, separating notifications for network, storage and compute would be generally good things I think.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>>We're getting notifications from quantum for networking and from nova for compute (although not as frequently as we would like).
<br>
> We are working with the cinder team on notifications there, too, but I don't know if that patch landed yet.</div>
<div><br>
I think you're missing my point here. The payload is so large and expensive now because it includes all things in one message. Storage, Network and Compute ... and they all stem from Compute (currently). Ideally these could be broken down from OneBigMessage
to a bunch of smaller messages in order to reduce dependency on/expense of the db (in compute anyway, where access is going away)<br>
<br>
-S<br>
<br>
</div>
<div>> Doug</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-size:10pt; font-family:Courier New">
<div style="font-size:16px; font-family:Times New Roman">
<div>
<div class="gmail_quote"><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-S</div>
<div><br>
</div>
</font></span></div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</body>
</html>