On Tue, 9 Jun 2015, gordon chung wrote:
i still like the idea of splitting polling and processing task.
pros:
- it moves load off poll agents and onto notificaiton agent
- we essentially get free healthcheck events by doing this
con:
to play devil's advocate. the one down side is that now there's two
levels of filtering (something we also ran into for declarative
meters.)
Many of the ideas we have floating around at the moment have
concerns about duplication/split-brain of any of:
* activity in the various processes
* configuration information
* data models
We should certain take care to avoid too much complexity arising
from these sorts of things but I hope we won't let it dissuade us from
decomposing our heavyweight monoliths into smaller pieces that are
more amenable to custom composition.
so now you need to ensure what you're polling matches up with what you
want to build (ie. you're polling the right things to build the data
you want or you're not polling stuff you don't intend to poll)... this
may or may not be a huge issue but it may be confusing to some.
True, but if we are moving in the direction of making configuration
more explicit and more contained then it will become a little easier
to manage. If we remove guesswork and ambiguity then it becomes
easier to create tools to automate the management (and distribution)
of configuration.
In the absence of additional feedback what I'm getting here is that
some prototyping is worth exploring and we'll evaluate as we go.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
