One of the outcomes from Juno will be horizontal scalability in the central agent and alarm evaluator via partitioning. The compute agent will get the same capability if you choose to use it, but it doesn't make quite as much sense.
I haven't investigated the alarm evaluator side closely yet, but one concern I have with the central agent partitioning is that, as far as I can tell, it will result in stored samples that give no indication of which (of potentially very many) central-agent it came from. This strikes me as a debugging nightmare when something goes wrong with the content of a sample that makes it all the way to storage. We need some way, via the artifact itself, to narrow the scope of our investigation. a) Am I right that no indicator is there? b) Assuming there should be one: * Where should it go? Presumably it needs to be an attribute of each sample because as agents leave and join the group, where samples are published from can change. * How should it be named? The never-ending problem. Thoughts?  https://review.openstack.org/#/c/113549/  https://review.openstack.org/#/c/115237/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev