You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AFAIK:
Fact-1: we like class type parser better than the function type ones.
Fact-2: We'd love to do our best to get the plugins(the @rule reducers) out of troubles.( Let it handle less things.)
Well, based on Fact-1, I am converting this multinode parser from func to class type(suggested by @PaulWay ).
What did I do:
I wrap all the "metadata.json" parsing funcs into one class MetaData,
and add (rhev, osp, docker, metadata) as MetaData's attributes.
To fit this in insights-plugin side, plugins can be changed like this:
an example(https://github.com/RedHatInsights/insights-plugins/pull/143)
I test above changes by upload a rhev-coordinator archive to my local insight-engine server, and it works.
(Not guarantee of fully test.)
When thinking about Fact-2, yes, this change becomes a burden to plugins.
(The existence of metadata.json file means a hit parser for all the @rules which requires it.)
So my question here is:
Should we convert this multinode parser to class type ? Or someone has better ideas to achieve this.
The text was updated successfully, but these errors were encountered:
Hey @JoySnow, we agree this needs to be addressed and are taking steps in the master branch. We'd still like each environment to have a dedicated component (OSP, RHEV, etc.), and for cluster rules to get the top level component while host level rules get the relevant Child component for a particular host. Have a look at https://github.com/RedHatInsights/insights-core/blob/master/insights/parsers/multinode.py. Note that the metadata decorator is just shorthand for parser(requires=["metadata.json"]) and that we prevent unwanted components from resolving by raising SkipComponent.
This is related to PR: https://github.com/RedHatInsights/insights-core/pull/161
AFAIK:
Fact-1: we like class type parser better than the function type ones.
Fact-2: We'd love to do our best to get the plugins(the @rule reducers) out of troubles.( Let it handle less things.)
Well, based on Fact-1, I am converting this multinode parser from func to class type(suggested by @PaulWay ).
What did I do:
I wrap all the "metadata.json" parsing funcs into one class
MetaData
,and add (
rhev
,osp
,docker
,metadata
) asMetaData
's attributes.To fit this in insights-plugin side, plugins can be changed like this:
an example(https://github.com/RedHatInsights/insights-plugins/pull/143)
I test above changes by upload a rhev-coordinator archive to my local insight-engine server, and it works.
(Not guarantee of fully test.)
When thinking about Fact-2, yes, this change becomes a burden to plugins.
(The existence of metadata.json file means a hit parser for all the @rules which requires it.)
So my question here is:
Should we convert this multinode parser to class type ? Or someone has better ideas to achieve this.
The text was updated successfully, but these errors were encountered: