@grnsft/if 0.3.4 → 0.4.0-beta.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.commitlintrc.js +0 -1
- package/.lintstagedrc.js +6 -0
- package/README.md +12 -8
- package/Refactor-migration-guide.md +6 -6
- package/github-processes.md +16 -42
- package/manifests/bugs/aggregation-error-wrong-metric.yml +6 -6
- package/manifests/bugs/azure-importer-ignoring-defaults.yml +3 -3
- package/manifests/bugs/azure-importer-incorrect-calculation.yml +2 -2
- package/manifests/bugs/mock-observations-failure-duration-is-zero.yml +34 -0
- package/manifests/bugs/pipeline-error-uninitialized-plugin.yml +1 -1
- package/manifests/bugs/pipeline-ordering-error.yml +6 -6
- package/manifests/bugs/sci-embodied-missing-resources-total.yml +23 -0
- package/manifests/examples/generics.yml +3 -3
- package/manifests/examples/instance-metadata.yml +36 -0
- package/manifests/examples/mock-cpu-util-to-carbon.yml +3 -3
- package/manifests/examples/nesting.yml +37 -10
- package/manifests/examples/pipeline-teads-sci.yml +17 -9
- package/manifests/examples/pipeline-with-aggregate.yml +24 -9
- package/manifests/examples/pipeline-with-mocks.yml +26 -9
- package/manifests/examples/sci.yml +131 -0
- package/manifests/examples/teads-curve.yml +78 -0
- package/manifests/features/aggregate-failure-inalid-metrics.yml +43 -0
- package/manifests/features/aggregate-failure-missing-metric-in-inputs.yml +43 -0
- package/manifests/integrations/cloud-metadata-divide-boavizta.yml +1 -1
- package/manifests/integrations/mock-obs-group-by-cloud-meta.yml +51 -0
- package/manifests/integrations/mock-obs-groupby.yml +2 -2
- package/manifests/integrations/mock-obs-time-sync.yml +1 -1
- package/manifests/plugins/cloud-metadata/failure-invalid-instance-type.yaml +21 -0
- package/manifests/plugins/cloud-metadata/failure-invalid-vendor.yaml +1 -1
- package/manifests/plugins/cloud-metadata/failure-missing-cloud-vendor.yml +21 -0
- package/manifests/plugins/cloud-metadata/success.yml +1 -1
- package/manifests/plugins/coefficient/failure-invalid-config-input-param.yml +1 -1
- package/manifests/plugins/coefficient/failure-output-param-is-null.yaml +24 -0
- package/manifests/plugins/coefficient/success.yml +1 -1
- package/manifests/plugins/csv-lookup/failure-missing-column.yml +26 -0
- package/manifests/plugins/csv-lookup/failure-missing-output.yml +26 -0
- package/manifests/plugins/csv-lookup/success-renaming.yml +26 -0
- package/manifests/plugins/csv-lookup/success.yml +26 -0
- package/manifests/plugins/divide/failure-denominator-equal-zero.yml +39 -0
- package/manifests/plugins/divide/failure-invalid-config-denominator.yml +1 -1
- package/manifests/plugins/divide/failure-missing-numerator.yml +39 -0
- package/manifests/plugins/divide/success.yml +2 -2
- package/manifests/plugins/groupby/failure-missing-cloud-instance-type.yml +49 -0
- package/manifests/plugins/interpolation/interpolation.yml +24 -0
- package/manifests/plugins/mock-observations/failure-invalid-config-cpu-range.yml +1 -1
- package/manifests/plugins/mock-observations/failure-invalid-memory-utilization-range.yml +34 -0
- package/manifests/plugins/mock-observations/failure-missing-timestamp-from-param.yml +34 -0
- package/manifests/plugins/mock-observations/success.yml +2 -2
- package/manifests/plugins/multiply/failure-input-parameter-is-missing.yml +1 -1
- package/manifests/plugins/multiply/success-with-multiple-inputs.yml +32 -0
- package/manifests/plugins/multiply/success.yml +3 -3
- package/manifests/plugins/regex/failure-missing-input-param.yml +1 -1
- package/manifests/plugins/regex/failure-not-matching-with-regex.yml +24 -0
- package/manifests/plugins/regex/success.yml +2 -2
- package/manifests/plugins/sci/failure-invalid-config-value.yml +2 -3
- package/manifests/plugins/sci/failure-missing-input-param.yml +27 -0
- package/manifests/plugins/sci/success.yml +5 -4
- package/manifests/plugins/{sci-m → sci-embodied}/failure-invalid-default-emission-value.yml +5 -6
- package/manifests/plugins/sci-embodied/failure-missing-expected-lifespan.yml +23 -0
- package/manifests/plugins/{sci-m → sci-embodied}/success.yml +5 -6
- package/manifests/plugins/shell/failure-invalid-command.yml +1 -1
- package/manifests/plugins/shell/success.yml +1 -2
- package/manifests/plugins/sum/failure-missing-input-param.yml +1 -1
- package/manifests/plugins/sum/failure-missing-output-param.yml +28 -0
- package/manifests/plugins/sum/success.yml +1 -1
- package/manifests/plugins/tdp-finder/failure-unsupported-physical-processor.yml +19 -0
- package/manifests/plugins/time-sync/failure-missing-global-config.yml +34 -0
- package/package.json +10 -2
- package/src/builtins/README.md +5 -5
- package/src/builtins/coefficient/README.md +92 -0
- package/src/builtins/csv-lookup/README.md +142 -0
- package/src/builtins/divide/README.md +95 -0
- package/src/builtins/exponent/README.md +97 -0
- package/src/builtins/interpolation/README.md +168 -0
- package/src/builtins/mock-observations/README.md +97 -0
- package/src/builtins/multiply/README.md +94 -0
- package/src/builtins/regex/README.md +91 -0
- package/src/builtins/sci/README.md +89 -0
- package/src/builtins/sci-embodied/README.md +110 -0
- package/src/builtins/shell/README.md +130 -0
- package/src/builtins/subtract/README.md +94 -0
- package/src/builtins/sum/README.md +91 -0
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
# SCI-Embodied
|
|
2
|
+
|
|
3
|
+
Software systems cause emissions through the hardware that they operate on, both through the energy that the physical hardware consumes and the emissions associated with manufacturing the hardware. Embodied carbon refers to the carbon emitted during the manufacture and eventual disposal of a component. It is added to the operational carbon (carbon emitted when a component is used) to give an overall SCI score.
|
|
4
|
+
|
|
5
|
+
Read more on [embodied carbon](https://github.com/Green-Software-Foundation/sci/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#embodied-emissions)
|
|
6
|
+
|
|
7
|
+
## Parameters
|
|
8
|
+
|
|
9
|
+
### Plugin config
|
|
10
|
+
|
|
11
|
+
Not Needed
|
|
12
|
+
|
|
13
|
+
### Inputs
|
|
14
|
+
|
|
15
|
+
- `device/emissions-embodied`: the sum of Life Cycle Assessment (LCA) emissions for the component
|
|
16
|
+
- `device/expected-lifespan`: the length of time, in seconds, between a component's manufacture and its disposal
|
|
17
|
+
- `resources-reserved`: the number of resources reserved for use by the software
|
|
18
|
+
- `resources-total`: the total number of resources available
|
|
19
|
+
- `duration`: the amount of time covered by an observation, in this context it is used as the share of the total life span of the hardware reserved for use by an application, in seconds.
|
|
20
|
+
|
|
21
|
+
> Note that if you have a plugin pipeline that adds `vcpus-allocated` and `vcpus-total` to each observation, such as the `cloud-metadata` plugin, those values will be used **in preference** to the given `resources-reserved` and `resources-total` fields.
|
|
22
|
+
|
|
23
|
+
## Returns
|
|
24
|
+
|
|
25
|
+
- `carbon-embodied`: the carbon emitted in manufacturing and disposing of a component, in gCO2eq
|
|
26
|
+
|
|
27
|
+
## Calculation
|
|
28
|
+
|
|
29
|
+
To calculate the embodied carbon, `m` for a software application, use the equation:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
m = te * ts * rs
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Where:
|
|
36
|
+
|
|
37
|
+
- `device/emissions-embodied` = Total embodied emissions; the sum of Life Cycle Assessment (LCA) emissions for the component.
|
|
38
|
+
|
|
39
|
+
- `timeShare` = Time-share; the share of the total life span of the hardware reserved for use by an application.
|
|
40
|
+
|
|
41
|
+
- `timeShare` is calculated as `duration/'device/expected-lifespan'`, where:
|
|
42
|
+
- `duration` = the length of time the hardware is reserved for use by the software.
|
|
43
|
+
- `device/expected-lifespan` = Expected lifespan: the length of time, in seconds, between a component's manufacture and its disposal.
|
|
44
|
+
|
|
45
|
+
- `resourceShare` = Resource-share; the share of the total available resources of the hardware reserved for use by an application.
|
|
46
|
+
- `resourceShare` is calculated as `resources-reserved/resources-total`, where:
|
|
47
|
+
- `resources-reserved` = Resources reserved; the number of resources reserved for use by the software.
|
|
48
|
+
- `resources-total` = Total Resources; the total number of resources available.
|
|
49
|
+
|
|
50
|
+
## Implementation
|
|
51
|
+
|
|
52
|
+
IF implements the plugin based on the logic described above. To run the plugin, you must first create an instance of `SciEmbodied`. Then, you can call `execute()` to return `m`.
|
|
53
|
+
|
|
54
|
+
## Usage
|
|
55
|
+
|
|
56
|
+
The following snippet demonstrates how to call the `sci-embodied` plugin from Typescript.
|
|
57
|
+
|
|
58
|
+
```typescript
|
|
59
|
+
import {SciEmbodied} from 'builtins';
|
|
60
|
+
|
|
61
|
+
const sciEmbodied = SciEmbodied();
|
|
62
|
+
const results = await sciEmbodied.execute([
|
|
63
|
+
{
|
|
64
|
+
'device/emissions-embodied': 200, // in gCO2e for total resource units
|
|
65
|
+
duration: 60 * 60 * 24 * 30, // time reserved in seconds, can point to another field "duration"
|
|
66
|
+
'device/expected-lifespan': 60 * 60 * 24 * 365 * 4, // lifespan in seconds (4 years)
|
|
67
|
+
'resources-reserved': 1, // resource units reserved / used
|
|
68
|
+
'resources-total': 1, // total resource units available
|
|
69
|
+
},
|
|
70
|
+
]);
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## Example manifest
|
|
74
|
+
|
|
75
|
+
IF users will typically call the plugin as part of a pipeline defined in a `manifest` file. In this case, instantiating the plugin is handled by `ie` and does not have to be done explicitly by the user. The following is an example `manifest` that calls `sci-embodied`:
|
|
76
|
+
|
|
77
|
+
```yaml
|
|
78
|
+
name: sci-embodied
|
|
79
|
+
description: simple demo invoking sci-embodied
|
|
80
|
+
tags:
|
|
81
|
+
initialize:
|
|
82
|
+
outputs:
|
|
83
|
+
- yaml
|
|
84
|
+
plugins:
|
|
85
|
+
sci-embodied:
|
|
86
|
+
method: SciEmbodied
|
|
87
|
+
path: 'builtins'
|
|
88
|
+
tree:
|
|
89
|
+
children:
|
|
90
|
+
child:
|
|
91
|
+
pipeline:
|
|
92
|
+
- sci-embodied # duration & config -> embodied
|
|
93
|
+
defaults:
|
|
94
|
+
device/emissions-embodied: 1533.120 # gCO2eq
|
|
95
|
+
device/expected-lifespan: 3 # 3 years in seconds
|
|
96
|
+
resources-reserved: 1
|
|
97
|
+
resources-total: 8
|
|
98
|
+
inputs:
|
|
99
|
+
- timestamp: 2023-07-06T00:00
|
|
100
|
+
duration: 3600
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
You can run this example `manifest` by executing the following command from the project root:
|
|
104
|
+
|
|
105
|
+
```sh
|
|
106
|
+
npm i -g @grnsft/if
|
|
107
|
+
ie --manifest manifests/plugins/sci-embodied.yml --output manifests/outputs/sci-embodied.yml
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
The results will be saved to a new `yaml` file in `./examples/outputs`.
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
# Shell Plugin
|
|
2
|
+
|
|
3
|
+
The `shell` is a wrapper enabling plugins implemented in any other programming language to be executed as a part of IF pipeline. For example, you might have a standalone plugin written in Python. `shell` spawns a subprocess to execute that Python plugin in a dedicated shell and pipes the results back into IF's Typescript process.
|
|
4
|
+
|
|
5
|
+
## Parameters
|
|
6
|
+
|
|
7
|
+
### Plugin global config
|
|
8
|
+
|
|
9
|
+
The plugin should be initialized as follows:
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
initialize:
|
|
13
|
+
plugins:
|
|
14
|
+
shell:
|
|
15
|
+
method: Shell
|
|
16
|
+
path: 'builtin'
|
|
17
|
+
global-config:
|
|
18
|
+
command: python3 /usr/local/bin/sampler
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
The `shell` plugin interface requires a path to the plugin command. This path is provided in the plugin configuration with the name command. The path should be appended by the execution command, for example, if the executable is a binary, the path would be prepended with `./` on a Linux system. If the plugin is a Python script, you can prepend `python`.
|
|
22
|
+
|
|
23
|
+
- `command`: the path to the plugin executable along with the execution command as it would be entered into a shell.
|
|
24
|
+
|
|
25
|
+
### Inputs
|
|
26
|
+
|
|
27
|
+
The parameters included in the `inputs` field in the `manifest` depend entirely on the plugin itself. A typical plugin might expect the following common data to be provided as `inputs`:
|
|
28
|
+
|
|
29
|
+
- `timestamp`: A timestamp for the specific input
|
|
30
|
+
- `duration`: The length of time these specific inputs cover
|
|
31
|
+
|
|
32
|
+
## Returns
|
|
33
|
+
|
|
34
|
+
The specific return types depend on the plugin being invoked. Typically, we would expect some kind of energy or carbon metric as an output, but it is also possible that plugins target different parts of the pipeline, such as data importers, adaptor plugins etc. Therefore, we do not specify return data for external plugins.
|
|
35
|
+
|
|
36
|
+
## Implementation
|
|
37
|
+
|
|
38
|
+
To run the plugin, you must first create an instance of `Shell` and call its `execute()` to run the external plugin.
|
|
39
|
+
|
|
40
|
+
```typescript
|
|
41
|
+
const output = Shell({command: '/usr/local/bin/sampler'});
|
|
42
|
+
const result = await output.execute([
|
|
43
|
+
{
|
|
44
|
+
timestamp: '2021-01-01T00:00:00Z',
|
|
45
|
+
duration: 3600,
|
|
46
|
+
'cpu/energy': 0.002,
|
|
47
|
+
'memory/energy': 0.000005,
|
|
48
|
+
},
|
|
49
|
+
]);
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Considerations
|
|
53
|
+
|
|
54
|
+
The `shell` is designed to run arbitrary external plugins. This means IF does not necessarily know what calculations are being executed in the external plugin. There is no strict requirement on the return type, as this depends upon the calculations and the position of the external plugin in a plugin pipeline. For example, one external plugin might carry out the entire end-to-end SCI calculation, taking in usage inputs and returning `sci`. In this case, the plugin is expected to return `sci` and it would be the only plugin invoked in the `manifest`.
|
|
55
|
+
|
|
56
|
+
However, it is also entirely possible to have external plugins that only deliver some small part of the overall pipeline, and rely on IF other plugins to do the rest.
|
|
57
|
+
|
|
58
|
+
Since the design space for external plugins is so large, it is up to external plugin developers to ensure compatibility with IF built-ins.
|
|
59
|
+
|
|
60
|
+
## Example manifest
|
|
61
|
+
|
|
62
|
+
IF users will typically call the shell plugin as part of a pipeline defined in a `manifest` file. In this case, instantiating and configuring the plugin is handled by and does not have to be done explicitly by the user. The following is an example `manifest` that calls an external plugin via `shell`. It assumes the plugin takes `cpu/energy` and `memory/energy` as inputs and returns `energy`:
|
|
63
|
+
|
|
64
|
+
```yaml
|
|
65
|
+
name: shell-demo
|
|
66
|
+
description:
|
|
67
|
+
tags:
|
|
68
|
+
initialize:
|
|
69
|
+
outputs:
|
|
70
|
+
- yaml
|
|
71
|
+
plugins:
|
|
72
|
+
sampler:
|
|
73
|
+
method: Shell
|
|
74
|
+
path: 'builtin'
|
|
75
|
+
global-config:
|
|
76
|
+
command: python3 /usr/local/bin/sampler
|
|
77
|
+
tree:
|
|
78
|
+
children:
|
|
79
|
+
child:
|
|
80
|
+
pipeline:
|
|
81
|
+
- sampler
|
|
82
|
+
inputs:
|
|
83
|
+
- timestamp: 2023-07-06T00:00
|
|
84
|
+
duration: 1 # Secs
|
|
85
|
+
cpu/energy: 0.002
|
|
86
|
+
memory/energy: 0.000005
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
In this hypothetical example, the plugin is written in Python and invoked by executing `python3 /usr/local/bin/sampler` in a shell.
|
|
90
|
+
The plugin should return an `output` looking as follows:
|
|
91
|
+
|
|
92
|
+
```yaml
|
|
93
|
+
name: shell-demo
|
|
94
|
+
description:
|
|
95
|
+
tags:
|
|
96
|
+
initialize:
|
|
97
|
+
outputs:
|
|
98
|
+
- yaml
|
|
99
|
+
plugins:
|
|
100
|
+
sampler:
|
|
101
|
+
method: Shell
|
|
102
|
+
path: 'builtin'
|
|
103
|
+
global-config:
|
|
104
|
+
command: python3 /usr/local/bin/sampler
|
|
105
|
+
tree:
|
|
106
|
+
children:
|
|
107
|
+
child:
|
|
108
|
+
pipeline:
|
|
109
|
+
- sampler
|
|
110
|
+
inputs:
|
|
111
|
+
- timestamp: 2023-07-06T00:00
|
|
112
|
+
duration: 1 # Secs
|
|
113
|
+
cpu/energy: 0.002
|
|
114
|
+
memory/energy: 0.000005
|
|
115
|
+
outputs:
|
|
116
|
+
- timestamp: 2023-07-06T00:00
|
|
117
|
+
duration: 1 # Secs
|
|
118
|
+
cpu/energy: 0.002
|
|
119
|
+
memory/energy: 0.000005
|
|
120
|
+
energy: 0.02 # added by plugin
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
You can run this example `manifest` by saving it as `manifests/plugins/shell.yml` and executing the following command from the project root:
|
|
124
|
+
|
|
125
|
+
```sh
|
|
126
|
+
npm i -g @grnsft/if
|
|
127
|
+
ie --manifest manifests/plugins/shell.yml --output manifests/outputs/shell.yml
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
The results will be saved to a new `yaml` file.
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# Subtract
|
|
2
|
+
|
|
3
|
+
`subtract` is a generic plugin for doing arithmetic subtractions of two or more values in an `input` array.
|
|
4
|
+
|
|
5
|
+
You provide the names of the values you want to subtract, and a name to use to add the subtraction to the output array.
|
|
6
|
+
|
|
7
|
+
For example, you could subtract `cpu/energy` and `network/energy` and name the result `offset/energy`. `offset/energy` would then be added to every observation in your input array as the diff of `cpu/energy` and `network/energy`.
|
|
8
|
+
|
|
9
|
+
## Parameters
|
|
10
|
+
|
|
11
|
+
### Plugin config
|
|
12
|
+
|
|
13
|
+
Two parameters are required in global config: `input-parameters` and `output-parameter`.
|
|
14
|
+
|
|
15
|
+
`input-parameters`: an array of strings. Each string should match an existing key in the `inputs` array
|
|
16
|
+
`output-parameter`: a string defining the name to use to add the result of the diff to the output array.
|
|
17
|
+
|
|
18
|
+
### Inputs
|
|
19
|
+
|
|
20
|
+
All of `input-parameters` must be available in the input array.
|
|
21
|
+
|
|
22
|
+
## Returns
|
|
23
|
+
|
|
24
|
+
- `output-parameter`: the subtraction of all `input-parameters` with the parameter name defined by `output-parameter` in global config.
|
|
25
|
+
|
|
26
|
+
## Calculation
|
|
27
|
+
|
|
28
|
+
```pseudocode
|
|
29
|
+
output = input0 - input1 - input2 ... - inputN
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Implementation
|
|
33
|
+
|
|
34
|
+
To run the plugin, you must first create an instance of `Subtract`. Then, you can call `execute()`.
|
|
35
|
+
|
|
36
|
+
```typescript
|
|
37
|
+
import {Subtract} from 'builtins';
|
|
38
|
+
|
|
39
|
+
const config = {
|
|
40
|
+
inputParameters: ['cpu/energy', 'network/energy'],
|
|
41
|
+
outputParameter: 'offset/energy',
|
|
42
|
+
};
|
|
43
|
+
|
|
44
|
+
const subtract = Subtract(config);
|
|
45
|
+
const result = subtract subtract.execute([
|
|
46
|
+
{
|
|
47
|
+
duration: 3600,
|
|
48
|
+
timestamp: '2021-01-01T00:00:00Z',
|
|
49
|
+
'cpu/energy': 0.005,
|
|
50
|
+
'memory/energy': 0.0001,
|
|
51
|
+
},
|
|
52
|
+
]);
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Example manifest
|
|
56
|
+
|
|
57
|
+
IF users will typically call the plugin as part of a pipeline defined in a manifest file. In this case, instantiating the plugin is handled by and does not have to be done explicitly by the user. The following is an example manifest that calls `subtract`:
|
|
58
|
+
|
|
59
|
+
```yaml
|
|
60
|
+
name: subtract demo
|
|
61
|
+
description:
|
|
62
|
+
tags:
|
|
63
|
+
initialize:
|
|
64
|
+
outputs:
|
|
65
|
+
- yaml
|
|
66
|
+
plugins:
|
|
67
|
+
subtract:
|
|
68
|
+
method: Subtract
|
|
69
|
+
path: 'builtin'
|
|
70
|
+
global-config:
|
|
71
|
+
input-parameters: ['cpu/energy', 'network/energy']
|
|
72
|
+
output-parameter: 'energy/diff'
|
|
73
|
+
tree:
|
|
74
|
+
children:
|
|
75
|
+
child:
|
|
76
|
+
pipeline:
|
|
77
|
+
- subtract
|
|
78
|
+
config:
|
|
79
|
+
subtract:
|
|
80
|
+
inputs:
|
|
81
|
+
- timestamp: 2023-08-06T00:00
|
|
82
|
+
duration: 3600
|
|
83
|
+
cpu/energy: 0.003
|
|
84
|
+
network/energy: 0.001
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
You can run this example by saving it as `./examples/manifests/test/subrtact.yml` and executing the following command from the project root:
|
|
88
|
+
|
|
89
|
+
```sh
|
|
90
|
+
npm i -g @grnsft/if
|
|
91
|
+
ie --manifest /manifests/plugins/subtract.yml --output manifests/outputs/subtract.yml
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
The results will be saved to a new `yaml` file in `manifests/outputs`.
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
# Sum
|
|
2
|
+
|
|
3
|
+
`sum` is a generic plugin for doing arithmetic sums of two or more values in an `input` array.
|
|
4
|
+
|
|
5
|
+
You provide the names of the values you want to sum, and a name to use to add the sum to the output array.
|
|
6
|
+
|
|
7
|
+
For example, you could add `cpu/energy` and `network/energy` and name the result `energy`. `energy` would then be added to every observation in your input array as the sum of `cpu/energy` and `network/energy`.
|
|
8
|
+
|
|
9
|
+
## Parameters
|
|
10
|
+
|
|
11
|
+
### Plugin config
|
|
12
|
+
|
|
13
|
+
Two parameters are required in global config: `input-parameters` and `output-parameter`.
|
|
14
|
+
|
|
15
|
+
`input-parameters`: an array of strings. Each string should match an existing key in the `inputs` array
|
|
16
|
+
`output-parameter`: a string defining the name to use to add the result of summing the input parameters to the output array.
|
|
17
|
+
|
|
18
|
+
### Inputs
|
|
19
|
+
|
|
20
|
+
All of `input-parameters` must be available in the input array.
|
|
21
|
+
|
|
22
|
+
## Returns
|
|
23
|
+
|
|
24
|
+
- `output-parameter`: the sum of all `input-parameters` with the parameter name defined by `output-parameter` in global config.
|
|
25
|
+
|
|
26
|
+
## Calculation
|
|
27
|
+
|
|
28
|
+
```pseudocode
|
|
29
|
+
output = input0 + input1 + input2 ... inputN
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Implementation
|
|
33
|
+
|
|
34
|
+
To run the plugin, you must first create an instance of `Sum`. Then, you can call `execute()`.
|
|
35
|
+
|
|
36
|
+
```typescript
|
|
37
|
+
const config = {
|
|
38
|
+
inputParameters: ['cpu/energy', 'network/energy'],
|
|
39
|
+
outputParameter: 'energy',
|
|
40
|
+
};
|
|
41
|
+
|
|
42
|
+
const sum = Sum(config);
|
|
43
|
+
const result = sum.execute([
|
|
44
|
+
{
|
|
45
|
+
timestamp: '2021-01-01T00:00:00Z',
|
|
46
|
+
duration: 3600,
|
|
47
|
+
'cpu/energy': 0.001,
|
|
48
|
+
'memory/energy': 0.0005,
|
|
49
|
+
},
|
|
50
|
+
]);
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Example manifest
|
|
54
|
+
|
|
55
|
+
IF users will typically call the plugin as part of a pipeline defined in a manifest file. In this case, instantiating the plugin is handled by and does not have to be done explicitly by the user. The following is an example manifest that calls `sum`:
|
|
56
|
+
|
|
57
|
+
```yaml
|
|
58
|
+
name: sum demo
|
|
59
|
+
description:
|
|
60
|
+
tags:
|
|
61
|
+
initialize:
|
|
62
|
+
outputs:
|
|
63
|
+
- yaml
|
|
64
|
+
plugins:
|
|
65
|
+
sum:
|
|
66
|
+
method: Sum
|
|
67
|
+
path: 'builtin'
|
|
68
|
+
global-config:
|
|
69
|
+
input-parameters: ['cpu/energy', 'network/energy']
|
|
70
|
+
output-parameter: 'energy'
|
|
71
|
+
tree:
|
|
72
|
+
children:
|
|
73
|
+
child:
|
|
74
|
+
pipeline:
|
|
75
|
+
- sum
|
|
76
|
+
config:
|
|
77
|
+
sum:
|
|
78
|
+
inputs:
|
|
79
|
+
- timestamp: 2023-08-06T00:00
|
|
80
|
+
duration: 3600
|
|
81
|
+
cpu/energy: 0.001
|
|
82
|
+
network/energy: 0.001
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
You can run this example by saving it as `./examples/manifests/sum.yml` and executing the following command from the project root:
|
|
86
|
+
|
|
87
|
+
```sh
|
|
88
|
+
ie --manifest ./examples/manifests/sum.yml --output ./examples/outputs/sum.yml
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
The results will be saved to a new `yaml` file in `./examples/outputs`.
|