<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.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="HOEnZb"><div class="h5"><br>
<br>
On 6/11/2014 10:01 AM, Eoghan Glynn wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks for bringing this to the list Matt, comments inline ...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tl;dr: some pervasive changes were made to nova to enable polling in<br>
ceilometer which broke some things and in my opinion shouldn't have been<br>
merged as a bug fix but rather should have been a blueprint.<br>
<br>
===<br>
<br>
The detailed version:<br>
<br>
I opened bug 1328694 [1] yesterday and found that came back to some<br>
changes made in ceilometer for bug 1262124 [2].<br>
<br>
Upon further inspection, the original ceilometer bug 1262124 made some<br>
changes to the nova os-floating-ips API extension and the database API<br>
[3], and changes to python-novaclient [4] to enable ceilometer to use<br>
the new API changes (basically pass --all-tenants when listing floating<br>
IPs).<br>
<br>
The original nova change introduced bug 1328694 which spams the nova-api<br>
logs due to the ceilometer change [5] which does the polling, and right<br>
now in the gate ceilometer is polling every 15 seconds.<br>
</blockquote>
<br>
IIUC that polling cadence in the gate is in the process of being reverted<br>
to the out-of-the-box default of 600s.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I pushed a revert in ceilometer to fix the spam bug and a separate patch<br>
was pushed to nova to fix the problem in the network API.<br>
</blockquote>
<br>
Thank you for that. The revert is just now approved on the ceilometer side,<br>
and is wending its merry way through the gate.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The bigger problem I see here is that these changes were all made under<br>
the guise of a bug when I think this is actually a blueprint. We have<br>
changes to the nova API, changes to the nova database API, CLI changes,<br>
potential performance impacts (ceilometer can be hitting the nova<br>
database a lot when polling here), security impacts (ceilometer needs<br>
admin access to the nova API to list floating IPs for all tenants),<br>
documentation impacts (the API and CLI changes are not documented), etc.<br>
<br>
So right now we're left with, in my mind, two questions:<br>
<br>
1. Do we just fix the spam bug 1328694 and move on, or<br>
2. Do we revert the nova API/CLI changes and require this goes through<br>
the nova-spec blueprint review process, which should have happened in<br>
the first place.<br>
</blockquote>
<br>
So just to repeat the points I made on the unlogged #os-nova IRC channel<br>
earlier, for posterity here ...<br>
<br>
Nova already exposed an all_tenants flag in multiple APIs (servers, volumes,<br>
security-groups etc.) and these would have:<br>
<br>
(a) generally pre-existed ceilometer's usage of the corresponding APIs<br>
<br>
and:<br>
<br>
(b) been tracked and proposed at the time via straight-forward LP bugs,<br>
as opposed to being considered blueprint material<br>
<br>
So the manner of the addition of the all_tenants flag to the floating_ips<br>
API looks like it just followed existing custom & practice.<br>
<br>
Though that said, the blueprint process and in particular the nova-specs<br>
aspect, has been tightened up since then.<br>
<br>
My preference would be to fix the issue in the underlying API, but to use<br>
this as "a teachable moment" ... i.e. to require more oversight (in the<br>
form of a reviewed & approved BP spec) when such API changes are proposed<br>
in the future.<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are there other concerns here? If there are no major objections to the<br>
code that's already merged, then #2 might be excessive but we'd still<br>
need docs changes.<br>
<br>
I've already put this on the nova meeting agenda for tomorrow.<br>
<br>
[1] <a href="https://bugs.launchpad.net/ceilometer/+bug/1328694" target="_blank">https://bugs.launchpad.net/<u></u>ceilometer/+bug/1328694</a><br>
[2] <a href="https://bugs.launchpad.net/nova/+bug/1262124" target="_blank">https://bugs.launchpad.net/<u></u>nova/+bug/1262124</a><br>
[3] <a href="https://review.openstack.org/#/c/81429/" target="_blank">https://review.openstack.org/#<u></u>/c/81429/</a><br>
[4] <a href="https://review.openstack.org/#/c/83660/" target="_blank">https://review.openstack.org/#<u></u>/c/83660/</a><br>
[5] <a href="https://review.openstack.org/#/c/83676/" target="_blank">https://review.openstack.org/#<u></u>/c/83676/</a><br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br></div></div>
While there is precedent for --all-tenants with some of the other APIs, I'm concerned about where this stops. When ceilometer wants polling on some other resources that the nova API exposes, will it need the same thing? Doing all of this polling for resources in all tenants in nova puts an undue burden on the nova API and the database.<br>
<br>
Can we do something with notifications here instead? That's where the nova-spec process would have probably caught this.</blockquote><div><br></div><div>++ to notifications and not polling.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>