tl;dr: some pervasive changes were made to nova to enable polling in
ceilometer which broke some things and in my opinion shouldn't have been
merged as a bug fix but rather should have been a blueprint.
===
The detailed version:
I opened bug 1328694 [1] yesterday and found that came back to some
changes made in ceilometer for bug 1262124 [2].
Upon further inspection, the original ceilometer bug 1262124 made some
changes to the nova os-floating-ips API extension and the database API
[3], and changes to python-novaclient [4] to enable ceilometer to use
the new API changes (basically pass --all-tenants when listing floating
IPs).
The original nova change introduced bug 1328694 which spams the nova-api
logs due to the ceilometer change [5] which does the polling, and right
now in the gate ceilometer is polling every 15 seconds.
I pushed a revert in ceilometer to fix the spam bug and a separate patch
was pushed to nova to fix the problem in the network API.
The bigger problem I see here is that these changes were all made under
the guise of a bug when I think this is actually a blueprint. We have
changes to the nova API, changes to the nova database API, CLI changes,
potential performance impacts (ceilometer can be hitting the nova
database a lot when polling here), security impacts (ceilometer needs
admin access to the nova API to list floating IPs for all tenants),
documentation impacts (the API and CLI changes are not documented), etc.
So right now we're left with, in my mind, two questions:
1. Do we just fix the spam bug 1328694 and move on, or
2. Do we revert the nova API/CLI changes and require this goes through
the nova-spec blueprint review process, which should have happened in
the first place.
Are there other concerns here? If there are no major objections to the
code that's already merged, then #2 might be excessive but we'd still
need docs changes.
I've already put this on the nova meeting agenda for tomorrow.
[1] https://bugs.launchpad.net/ceilometer/+bug/1328694
[2] https://bugs.launchpad.net/nova/+bug/1262124
[3] https://review.openstack.org/#/c/81429/
[4] https://review.openstack.org/#/c/83660/
[5] https://review.openstack.org/#/c/83676/
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
