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
What
Update behaviour of explainer feature. No we have it working and have been experimenting with it, we're not particularly happy with how we designed it, so we'll try making some behavioural changes to the feature.
Why
The block of information returned by explainer isn't that helpful for end users. The problem it is supposed to solve is that it is difficult to track what parameters are in a manifest. Today the explain block isn't much easier to read than the initialize block. We really need to rethink and make sure that a user can use the explain feature to understand what a parameter is and what it does.
Context
We should refocus on parameters, not plugins. We can understand plugins from their docs and the initialize information.
param-name
plugins: //what plugins use this param?
unit:
description:
aggregation-method:
Seting the parameter metadata can still be the same as it is today, but the logic and the way the data is displayed in explain needs to change.
Let's say two plugins both use cpu/energy. Both plugins have default metadata in their source code, and maybe it's overwritten in the manifest file - doesn't matter either way, the point is that metadata is available for both. It also doesn't matter whether the parameter is an input or an output in the plugins, we only care that it is used in some way. As long as the units and aggregation method are the same for each instance of the parameter, we can proceed, and should return the following in the explain block:
cpu/energy
plugins: [plugin-1, plugin-2]
unit: kWh
description: energy consumed by the CPU in kWh
aggregation-method: sum
However, if we see that the two instances of the parameter have different units or aggregation methods, we should just error out.
ERROR: your manifest uses two instances of cpu/energy with different units. Please check that you are using consistent units for cpu/energy throughout your manifest.
Prerequisites/resources
SoW (scope of work)
explain feature behaviour updated
documentation updated
test cases added
Acceptance criteria
Given (Setup): Describes the initial state of the system or the preconditions for a change.
When (Action): Describes the specific action or behavior that is being tested/changed.
Then (Assertion): Defines the expected outcome or behavior of the system after the action in the "When" step is performed.
The text was updated successfully, but these errors were encountered:
What
Update behaviour of explainer feature. No we have it working and have been experimenting with it, we're not particularly happy with how we designed it, so we'll try making some behavioural changes to the feature.
Why
The block of information returned by
explainer
isn't that helpful for end users. The problem it is supposed to solve is that it is difficult to track what parameters are in a manifest. Today the explain block isn't much easier to read than theinitialize
block. We really need to rethink and make sure that a user can use theexplain
feature to understand what a parameter is and what it does.Context
We should refocus on parameters, not plugins. We can understand plugins from their docs and the initialize information.
Instead of returning:
we should instead return:
Seting the parameter metadata can still be the same as it is today, but the logic and the way the data is displayed in
explain
needs to change.Let's say two plugins both use
cpu/energy
. Both plugins have default metadata in their source code, and maybe it's overwritten in the manifest file - doesn't matter either way, the point is that metadata is available for both. It also doesn't matter whether the parameter is an input or an output in the plugins, we only care that it is used in some way. As long as the units and aggregation method are the same for each instance of the parameter, we can proceed, and should return the following in theexplain
block:However, if we see that the two instances of the parameter have different units or aggregation methods, we should just error out.
Prerequisites/resources
SoW (scope of work)
Acceptance criteria
Given (Setup): Describes the initial state of the system or the preconditions for a change.
When (Action): Describes the specific action or behavior that is being tested/changed.
Then (Assertion): Defines the expected outcome or behavior of the system after the action in the "When" step is performed.
The text was updated successfully, but these errors were encountered: