Pipeline configuration cleanup
Pipelines have are configured with the names of the counters they should produce, but they don't have a real list. Instead they have a set of wildcard patterns and negation options that can be used to test an individual counter by name. We should resolve that list fully when the pipeline is configured, so it is possible for the pipeline manager to ask the pipeline for a list of the counters supported by a pipeline. That will allow us to have the PublisherTask ask the pipeline which counters to collect, instead of having to work it out in advance.
Blueprint information
- Status:
- Complete
- Approver:
- Julien Danjou
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Doug Hellmann
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
-
next
- Started by
- Completed by
- gordon chung
Related branches
Related bugs
Sprints
Whiteboard
Currently user can list explicitly all counter interested already. (Valid counters definition is all "included counter names", all "excluded counter names", wildcard and "excluded counter names", or only wildcard.)
Instead of change it in the configuration, how about still keep the configuration as wildcard patterns and negation options , How about when pipeline manager setup the pipelines, it translate all wildcard patterns and negation options into an explicitly counter list?
The side effect is then pipeline need consult the pollsters for the counters supported, a bit tightly connected. But I think anyway we need something to connect the pollster and pipline together.
--jyh
Yes, what I was trying to describe was having the configuration stay the way it is now, but also provide a convenient way to compute the list of pollsters needed. So if there was a get_supported_
Rather than putting this in the pipeline, maybe what we really need is a way for the pipeline to report its rules, and for something else to evaluate the rules against the list of available pollsters. -- drh
-------
What if we remove the notification -> sample plugins and push that conversion declaration to pipeline.yaml? One declaration per meter where you can describe the initial sample for that meter's samples from white-listing event types and their notification attributes via dot notation?
- Thomas
marking obsolete as it's not really relevant in current architecture where sample and events are defined by meter and event definition files respectively -- gordc (10.11.15)
Work Items
Dependency tree
* Blueprints in grey have been implemented.
