<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 3:06 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 class="im"><br>
<br>
On 08/16/2013 04:58 PM, Doug Hellmann wrote:<br>
> The notification messages don't translate 1:1 to database records. Even<br>
> if the notification payload includes multiple resources, we will store<br>
> those as multiple individual records so we can query against them. So it<br>
> seems like sending individual notifications would let us distribute the<br>
> load of processing the notifications across several collector instances,<br>
> and won't have any effect on the data storage requirements.<br>
<br>
<br>
</div>Well, they would. Each .exists would result in a Event record being<br>
stored with the underlying raw json (pretty big) at the very least.<br></blockquote><div><br></div><div>Ah, you're right, I forgot about the new event table. I was just thinking of the samples.</div><div><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">
<br>
Like Alex said, if each customer has a daily week-long rolling backup<br>
over 100k instances that's 700k .exists records.<br>
<br>
We have some ideas we're kicking around internally about alternative<br>
approaches, but right now I think we have to design for 1 glance .exists<br>
per image (worst case) or 1 glance event per tenant (better case) and<br>
hope that deploying per-cell will help spread the load ... but it'll<br>
suck for making aggregated reports per region.<br>
<br>
Phil, like Doug said, I don't think switching from per-instance to<br>
per-tenant or anything else will really affect the end result. The<br>
event->meter mapping will have to break it down anyway.<br>
<br>
<br>
-S<br>
<div class="im"><br>
><br>
> Doug<br>
><br>
><br>
> On Thu, Aug 15, 2013 at 11:58 AM, Alex Meade <<a href="mailto:alex.meade@rackspace.com">alex.meade@rackspace.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:alex.meade@rackspace.com">alex.meade@rackspace.com</a>>> wrote:<br>
><br>
>     I don't know any actual numbers but I would have the concern that<br>
>     images tend to stick around longer than instances. For example, if<br>
>     someone takes daily snapshots of their server and keeps them around<br>
>     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>
><br>
>     -Alex<br>
><br>
>     -----Original Message-----<br>
>     From: "Doug Hellmann" <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a><br>
</div><div class="im">>     <mailto:<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"<br>
>     <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
</div><div class="im">>     <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
>     Subject: Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing<br>
>     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>
</div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>     <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<br>
>     "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><br>
</div><div><div class="h5">>     <mailto:<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,<br>
>     Trove and<br>
>     > Neutron all emit exists events on a per-instance basis....a<br>
>     consumer would<br>
>     > have to figure out a way to handle/unpack these separately if they<br>
>     needed a<br>
>     > granular feed. Not the end of the world, I suppose, but a bit<br>
>     inconsistent.<br>
>     ><br>
>     > And a minor quibble: batching would also make it a much bigger<br>
>     issue if a<br>
>     > consumer missed a notification....though I guess you could<br>
>     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.<br>
>     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<br>
>     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<br>
>     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<br>
>     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<br>
>     <<a href="mailto:julien@danjou.info">julien@danjou.info</a> <mailto:<a href="mailto:julien@danjou.info">julien@danjou.info</a>><br>
</div></div><div><div class="h5">>     > > > <mailto:<a href="mailto:julien@danjou.info">julien@danjou.info</a> <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,<br>
>     does this<br>
>     > > >     sound like<br>
>     > > >     > something Ceilometer would find value in and use? If so,<br>
>     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<br>
>     ability to<br>
>     > drop<br>
>     > > >     our pollster at some time.<br>
>     > > >     I'm just concerned with the type of notification you'd<br>
>     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>
</div></div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>     > > > <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>
</div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>     > > <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>
</div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>     > <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>
</div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="HOEnZb"><div class="h5">>     <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>
><br>
</div></div></blockquote></div><br></div></div>