<div dir="ltr">The notification messages don't translate 1:1 to database records. Even if the notification payload includes multiple resources, we will store those as multiple individual records so we can query against them. So it seems like sending individual notifications would let us distribute the load of processing the notifications across several collector instances, and won't have any effect on the data storage requirements.<div>
<br></div><div>Doug<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 11:58 AM, Alex Meade <span dir="ltr"><<a href="mailto:alex.meade@rackspace.com" target="_blank">alex.meade@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't know any actual numbers but I would have the concern that images tend to stick around longer than instances. For example, if someone takes daily snapshots of their server and keeps them around for a long time, the number of exists events would go up and up.<br>

<br>
Just a thought, could be a valid avenue of concern.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Alex<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: "Doug Hellmann" <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
Sent: Thursday, August 15, 2013 11:17am<br>
To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing In Glance<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
Nova generates a single exists event for each instance, and that doesn't<br>
cause a lot of trouble as far as I've been able to see.<br>
<br>
What is the relative number of images compared to instances in a "typical"<br>
cloud?<br>
<br>
Doug<br>
<br>
<br>
On Tue, Aug 13, 2013 at 7:20 PM, Neal, Phil <<a href="mailto:phil.neal@hp.com">phil.neal@hp.com</a>> wrote:<br>
<br>
> I'm a little concerned that a batch payload won't align with "exists"<br>
> events generated from other services. To my recollection, Cinder, Trove and<br>
> Neutron all emit exists events on a per-instance basis....a consumer would<br>
> have to figure out a way to handle/unpack these separately if they needed a<br>
> granular feed. Not the end of the world, I suppose, but a bit inconsistent.<br>
><br>
> And a minor quibble: batching would also make it a much bigger issue if a<br>
> consumer missed a notification....though I guess you could counteract that<br>
> by increasing the frequency (but wouldn't that defeat the purpose?)<br>
><br>
> ><br>
> ><br>
> ><br>
> > On 08/13/2013 04:35 PM, Andrew Melton wrote:<br>
> > >> I'm just concerned with the type of notification you'd send. It has to<br>
> > >> be enough fine grained so we don't lose too much information.<br>
> > ><br>
> > > It's a tough situation, sending out an image.exists for each image with<br>
> > > the same payload as say image.upload would likely create TONS of<br>
> traffic.<br>
> > > Personally, I'm thinking about a batch payload, with a bare minimum of<br>
> the<br>
> > > following values:<br>
> > ><br>
> > > 'payload': [{'id': 'uuid1', 'owner': 'tenant1', 'created_at':<br>
> > > 'some_date', 'size': 100000000},<br>
> > >                {'id': 'uuid2', 'owner': 'tenant2', 'created_at':<br>
> > > 'some_date', 'deleted_at': 'some_other_date', 'size': 200000000}]<br>
> > ><br>
> > > That way the audit job/task could be configured to emit in batches<br>
> which<br>
> > > a deployer could tweak the settings so as to not emit too many<br>
> messages.<br>
> > > I definitely welcome other ideas as well.<br>
> ><br>
> > Would it be better to group by tenant vs. image?<br>
> ><br>
> > One .exists per tenant that contains all the images owned by that tenant?<br>
> ><br>
> > -S<br>
> ><br>
> ><br>
> > > Thanks,<br>
> > > Andrew Melton<br>
> > ><br>
> > ><br>
> > > On Tue, Aug 13, 2013 at 4:27 AM, Julien Danjou <<a href="mailto:julien@danjou.info">julien@danjou.info</a><br>
> > > <mailto:<a href="mailto:julien@danjou.info">julien@danjou.info</a>>> wrote:<br>
> > ><br>
> > >     On Mon, Aug 12 2013, Andrew Melton wrote:<br>
> > ><br>
> > >     > So, my question to the Ceilometer community is this, does this<br>
> > >     sound like<br>
> > >     > something Ceilometer would find value in and use? If so, would<br>
> this be<br>
> > >     > something<br>
> > >     > we would want most deployers turning on?<br>
> > ><br>
> > >     Yes. I think we would definitely be happy to have the ability to<br>
> drop<br>
> > >     our pollster at some time.<br>
> > >     I'm just concerned with the type of notification you'd send. It<br>
> has to<br>
> > >     be enough fine grained so we don't lose too much information.<br>
> > ><br>
> > >     --<br>
> > >     Julien Danjou<br>
> > >     // Free Software hacker / freelance consultant<br>
> > >     // <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">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>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">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>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">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>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
</div></div></blockquote></div><br></div></div></div>