openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13805
[metering] proposed changes to pollster plugin API
The "Common Pollster class" changes [1] from Kobagana Kumar reminded me of
something I thought of when I was trying to figure out how to solve the
instance-delete-notification problem in bug #1005944 [2].
The current implementation of the pollster plugins assumes that they could
be polling anything at all (compute, network, volume, etc.) and leaves it
up to the plugin to determine what resources to scan. That means each
plugin queries the database for the list of instances, connects to libvirt,
then asks for the data it needs. Kobagana is correct that we should only
have one copy of that code, but the placement in the patch is wrong, for a
reason that is only really clear if you think about both problems.
In order to poll about an instance before it is deleted, we will need to
add a new way to call the pollsters. That calling path will need to let the
caller pass in the instance being deleted to avoid polling *all* instances
on the compute node (primarily because if there are a lot of instances,
polling all of them may take longer than we want to wait before finishing
the delete operation).
I propose that we move the code that connects to libvirt and gets the list
of instances into the class that calls the pollsters (AgentManager) so we
can support both calling patterns. That will make the AgentManager the
ComputeAgentManager (since network pollsters won't necessarily need to talk
to libvirt) and we will need other managers for calling pollsters that do
not use compute resources. I don't see that as a problem, since those
pollsters probably won't run on the compute nodes anyway so we will want
them to be loaded in another agent process.
What do the rest of you think about this change?
Doug
[1] https://review.stackforge.org/#/c/259/
[2] https://bugs.launchpad.net/ceilometer/+bug/1005944
Follow ups