@grnsft/if 0.0.2

package/.devcontainer/devcontainer.json

@@ -0,0 +1,38 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the
+// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
+{
+	"name": "Node.js & TypeScript",
+	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
+	"image": "mcr.microsoft.com/devcontainers/typescript-node:1-18",
+
+	// Features to add to the dev container. More info: https://containers.dev/features.
+	"features": {
+		"ghcr.io/devcontainers/features/node:1": {}
+	},
+
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	"postCreateCommand": ". ${NVM_DIR}/nvm.sh && nvm install --lts",
+
+	"postStartCommand": "yarn install",
+
+	// Configure tool-specific properties.
+	"customizations": {
+	// Configure properties specific to VS Code.
+	"vscode": {
+		// Set *default* container specific settings.json values on container create.
+		"settings": { 
+		},
+		
+		// Add the IDs of extensions you want installed when the container is created.
+		"extensions": [
+			"esbenp.prettier-vscode",
+			"ms-vscode.makefile-tools"
+		]
+	}
+},
+	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
+	// "remoteUser": "root"
+}

package/.editorconfig

@@ -0,0 +1,8 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+insert_final_newline = true

package/.env.example

@@ -0,0 +1,9 @@
+AZURE_CLIENT_ID: 
+AZURE_TENANT_ID: 
+AZURE_CLIENT_SECRET: 
+AZURE_CLIENT_SECRET_ID: 
+AZURE_APPLICATION_ID: 
+AZURE_SUBSCRIPTION_ID: 
+AZURE_RESOURCE_ID: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachines/<vm-name>
+AZURE_RESOURCE_GROUP_NAME: 
+AZURE_VM_NAME: 

package/.eslintignore

@@ -0,0 +1,4 @@
+build/
+dist/
+src/**/**.d.ts
+src/**/**.js

package/.eslintrc.json

@@ -0,0 +1,8 @@
+{
+  "extends": "./node_modules/gts/",
+  "rules": {
+    "@typescript-eslint/no-explicit-any": [
+      "off"
+    ]
+  }
+}

package/.github/ISSUE_TEMPLATE/agenda.md

@@ -0,0 +1,36 @@
+---
+name: Agenda
+about: The standard agenda template for carbon ql
+title: "GSF IEF Meeting Agenda yyyy-mm-dd"
+labels: agenda
+assignees: ''
+
+---
+
+Time 11:30am (GMT) / 4:00pm (IST) - See the time in your [timezone](https://everytimezone.com/s/e7e219dd)
+
+- Lead – @srini1978 (Microsoft)
+- Co-Lead @navveenb (Accenture)
+- PM – @jawache (GSF)
+
+## Antitrust Policy
+Joint Development Foundation meetings may involve participation by industry competitors, and it is the intention of the Joint Development Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.
+
+If you have questions about these matters, please contact your company counsel or counsel to the Joint Development Foundation, DLA Piper.
+
+## Roll Call
+Please add 'Attended' to this issue during the meeting to denote attendance.
+Any untracked attendees will be added by the GSF team below:
+
+## Agenda
+- [ ] Press Record!
+
+### PRs
+- [ ] 
+
+### Discussions
+- [ ] 
+
+### Issues
+- [ ] Discuss in-progress/blocked issues on project board: https://github.com/orgs/Green-Software-Foundation/projects/26/views/1
+- [ ] AOB

package/.github/ISSUE_TEMPLATE/blank-issue.md

@@ -0,0 +1,10 @@
+---
+name: Blank issue
+about: Blank issue
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+

package/.github/ISSUE_TEMPLATE/feedback.md

@@ -0,0 +1,42 @@
+---
+name: Feedback
+about: Submiting feedback on the IEF implementation
+title: "Feedback - "
+labels: feedback
+assignees: ''
+---
+
+## Scope
+
+What does your feedback relate to?
+
+- [] Project aims/objectives
+- [] Repository structure 
+- [] Model plugin
+- [] Rimpl code 
+- [] Documentation
+- [] Tests
+- [] Other
+
+## Details
+
+Does your feedback relate to a specific problem that can be demonstrated and reproduced? If so, please provide details of how to repro below.
+Include your platform config and the version of IEF you are using (e.g. Ubuntu 20.04, running latest dev branch on XX date).
+
+## Expected Behaviour
+
+What do things look like if they are going right?
+e.g. "the github issue board is cleared out every X days"
+
+## Actual behaviour
+
+How are things actually working?
+e.g. "issues are sitting on the board for over X days"
+
+## Proposed actions
+
+What fixes do you propose?
+e.g. "please define a response time of X days for issues and publish in the project README"
+
+
+**Note: We will take all feedback seriously. Please be polite and constructive - aggressive or abusive feedback will simply be deleted.**

package/.github/ISSUE_TEMPLATE/model-plugin.md

@@ -0,0 +1,63 @@
+---
+name: Model Plugin
+about: Submiting a request to create a model plugin
+title: "Model Plugin - "
+labels: model
+assignees: ''
+---
+
+- **What**: 
+- **Why**: 
+- **DoD**:
+- [ ] Does the model meet the specification?
+- [ ] Does the model have complete test coverage, including edge cases, happy path and error cases?
+- [ ] Is the code documented?
+
+## Config
+- `variable`: If this variable is present in the top level config what behaviour does it trigger? What is the default value if none is provided?
+
+## Inputs
+_List the variables this model expects in an input input_
+- `variable`: Description
+
+## Outputs
+_List the variables this model exports out as an impact_
+- `variable`: Description
+
+## Behavior
+What does the model do to turn the inputs into outputs? List any important equations or references.
+
+## Assumptions
+What are the core assumptions this model makes?
+
+## Limitations
+In what situations is this model limited in it's function, behaviour, accuracy etc...
+
+## Example
+Provide at least one example of some input config and inputs. This is in pimpl format not rimpl format, so the config is the global config and all parameters must be present on the input.
+
+### Input
+
+```yaml
+config:
+ key: value
+inputs: 
+  - timestamp: 2023-07-06T00:00
+    duration: 3600
+```
+
+### Output
+
+```yaml
+config:
+ key: value
+inputs: 
+  - timestamp: 2023-07-06T00:00
+    duration: 3600
+    yyyy: zzzz
+outputs: 
+  - timestamp: 2023-07-06T00:00
+    duration: 3600
+    yyyy: zzzz
+    aaaa: bbbb
+```

package/.github/ISSUE_TEMPLATE/user-story.md

@@ -0,0 +1,10 @@
+---
+name: User story
+about: This describes a user story for IEF
+title: "[User story] ...."
+labels: user-story
+assignees: ''
+
+---
+
+As a <type of user> I want <some goal> so that <some reason>.

package/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,21 @@
+### Types of changes
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply. -->
+- [ ] Enhancement (project structure, spelling, grammar, formatting)
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+- [ ] My code follows the code style of this project.
+- [ ] My change requires a change to the documentation.
+- [ ] I have updated the documentation accordingly.
+- [ ] I have added tests to cover my changes.
+- [ ] All new and existing tests passed.
+
+
+### A description of the changes proposed in the Pull Request
+<!--- Provide a small description of the changes. -->
+- 
+- 
+
+
+<!-- Make sure tests and lint pass on CI. -->
+

package/.github/workflows/nodejs-ci.yml

@@ -0,0 +1,34 @@
+name: Node.js CI
+
+on: push
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: 'yarn'
+
+      - name: 'setup python'
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+
+      - name: Install dependencies
+        run: yarn install
+
+      - name: Copy Sample CLI Mocker to bin folder
+        run: pip3 install pyyaml && cp src/lib/shell-imp/sampler /usr/local/bin/sampler && chmod +x /usr/local/bin/sampler
+
+      - name: Run lint
+        run: yarn lint
+
+      - name: Run tests
+        run: yarn test --silent

package/.gitmodules

@@ -0,0 +1,3 @@
+[submodule "third-party/ccf-coefficients"]
+	path = third-party/ccf-coefficients
+	url = https://github.com/cloud-carbon-footprint/ccf-coefficients

package/.prettierrc.js

@@ -0,0 +1,3 @@
+module.exports = {
+  ...require('gts/.prettierrc.json')
+}

package/CONTRIBUTING.md

@@ -0,0 +1,194 @@
+# Contributing to IEF <!-- omit from toc -->
+
+First off, thanks for taking the time to contribute! 🎉
+
+The following document is a rule set of guidelines for contributing.
+
+## Table of Contents <!-- omit from toc -->
+
+- [Code Contributions](#code-contributions)
+    - [Step 1: Clone](#step-1-clone)
+    - [Step 2: Branch](#step-2-branch)
+    - [Step 3: Commit](#step-3-commit)
+    - [Step 4: Sync](#step-4-sync)
+    - [Step 5: Push](#step-5-push)
+    - [Step 6: Pull Request](#step-6-pull-request)
+- [Commit message guidelines](#commit-message-guidelines)
+- [Coding guidelines](#coding-guidelines)
+    - [Code structuring patterns](#code-structuring-patterns)
+        - [Object Oriented Programming](#object-oriented-programming)
+        - [Functional Programming](#functional-programming)
+    - [Naming patterns](#naming-patterns)
+    - [Documentation](#documentation)
+    - [Writing tests](#writing-tests)
+
+## Code Contributions
+
+#### Step 1: Clone
+
+Clone the project on [GitHub](git@github.com:Green-Software-Foundation/ief.git)
+   
+   ```bash
+   $ git clone git@github.com:Green-Software-Foundation/ief.git
+   $ cd ief
+   ```
+   
+For developing new features and bug fixes, the development branch should be pulled and built upon.
+
+#### Step 2: Branch
+
+Create new branch from main (`staging` or `master`), which will contain your new feature, fix or change. 
+
+    ```bash
+    $ git checkout -b <topic-branch-name>
+    ```
+
+#### Step 3: Commit
+
+Make sure git knows your name and email address:
+
+   ```bash
+   $ git config --global user.name "Example User"
+   $ git config --global user.email "user@example.com"
+   ```
+
+Commiting multiple files with changes on multiple resources is not allowed.
+Commit message should clearly describe on which resource changes are made.
+
+Add and commit:
+
+   ```bash
+   $ git add my/changed/files
+   $ git commit
+   ```  
+    
+Commit your changes in logical chunks. Please do not push all changes in one commit.
+
+> Run `yarn fix` before commiting for not having conflict with CI linter.
+
+Please adhere to these [Commit message guidelines](#commit-message-guidelines)
+   or your code is unlikely be merged into the main project.
+
+#### Step 4: Sync
+
+Use git pull/merge to synchronize your work with the main repository.
+
+   ```bash
+   $ git pull origin dev
+   ```
+   
+#### Step 5: Push
+
+Push your topic branch:
+
+   ```bash
+   $ git push origin <topic-branch-name>
+   ```
+
+#### Step 6: Pull Request
+
+Open a Pull Request with a clear title and description according to [template](.github/PULL_REQUEST_TEMPLATE.md).
+
+Pull request should pass all CI which are defined, should have at least one approve. It should adher to the specification for getting approved.
+
+CI included lint checks, running tests, and etc.
+
+## Commit message guidelines
+
+The commit message should describe what changed and why.
+
+   1. The first line should:
+       * contain a short description of the change
+       * be 60 characters or less
+       * be prefixed with the name of the changed subsystem
+       * be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
+         like function/variable names
+        
+       Examples:
+       
+       ```
+        util: add getInitializedModel method to models.
+        deps: add express package to dependencies.
+        service: refactor get user.
+       ```
+   2. Keep the second line blank. 
+          
+   3. Wrap all other lines at 72 columns:
+      * describe each line in logical chunks
+      * start each line with: space hyphen space ( - ...)
+      * be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
+        like function/variable names
+      
+      Examples:
+      
+      ```    
+        - remove deprecated logger
+        - refactor some method
+        - add JSDoc on existing function
+      ```
+## Coding guidelines
+
+#### Code structuring patterns
+
+Avoid having functions which are responsible to do multiple things at the same time. Make sure one function/method does one thing, and does it well. 
+
+###### Object Oriented Programming
+
+While following `Object Oriented Programming` paradigm, it's important to follow [SOLID](https://en.wikipedia.org/wiki/SOLID) principles.
+
+###### Functional Programming
+
+When designing module of the application in `Functional Programming` paradigm, the key to follow [basic](https://dev.to/jamesrweb/principles-of-functional-programming-4b7c) principles.
+
+#### Naming patterns
+
+Make sure your `class/function/variable` describes exactly what it does. Avoid using shortened words like txt, arr while doing naming decision. As a naming pattern `camel case` should be used.
+
+```ts
+❌ const a = "<MOCK_VALUE_HERE>"
+✅ const mockValue = "<MOCK_VALUE_HERE>"
+
+❌ const a = (txt: string) => console.log(txt)
+✅ const logMessage = (message: string) => console.log(message)
+```
+
+#### Documentation
+
+Every logical unit (`Class, function, method`) should be covered with appropriate documentation. For documenting such, multi-line comment style is used.
+
+```ts
+❌ const a = (message: string) => console.log(message)
+
+✅
+/**
+ * Logs given `message` to console.
+ **/
+const logMessage = (message: string) => console.log(message)
+```
+
+For documenting variable, expression, single line comments can be used after declaration.
+
+```ts
+class MockClass {
+     // this is a mock field
+  ❌ private mockField: string = "mock-field"
+  ✅ private mockField: string = "mock-field" // Single line documenting style is used.
+}
+```
+
+#### Writing tests
+
+One test file should be responsible for one module. `describe` blocks should be used for module and function/method description. First `describe` should follow `resource/module: ` pattern. Second describe title should follow  `method(): ` pattern. Test units can use either `test` or `it`, title should exactly describe behaviour and input argument. Make sure each test case covers one branch.
+
+See example: 
+```ts
+describe('util/args: ', () => {
+   describe('parseProcessArgument(): ', () => {
+      it('logs help message if property present in env.', () => {
+         ...
+      })
+   })
+})
+```
+
+*[⬅️ back to the root](/README.md#ief)*

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023 Green Software Foundation
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/Makefile

@@ -0,0 +1,16 @@
+
+
+#Converts the CSV files from CCF Coefficients Database to JSON.
+ccf-data:
+	cat third-party/ccf-coefficients/data/aws-instances.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/aws-instances.json
+	cat third-party/ccf-coefficients/output/coefficients-aws-use.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/aws-use.json
+	cat third-party/ccf-coefficients/output/coefficients-aws-embodied.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/aws-embodied.json
+	cat third-party/ccf-coefficients/data/gcp-instances.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/gcp-instances.json
+	cat third-party/ccf-coefficients/output/coefficients-gcp-use.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/gcp-use.json
+	cat third-party/ccf-coefficients/output/coefficients-gcp-embodied.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/gcp-embodied.json
+	cat third-party/ccf-coefficients/data/azure-instances.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/azure-instances.json
+	cat third-party/ccf-coefficients/output/coefficients-azure-use.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/azure-use.json
+	cat third-party/ccf-coefficients/output/coefficients-azure-embodied.csv | python -c 'import csv, json, sys; print(json.dumps([dict(r) for r in csv.DictReader(sys.stdin)]))' > lib/ccf/azure-embodied.json
+
+install-shell-imp:
+  cp src/lib/shell-imp/sampler /usr/local/bin/sampler

package/README.md

@@ -0,0 +1,67 @@
+# Impact Engine Framework
+
+[Impact Engine Framework](https://greensoftwarefoundation.atlassian.net/wiki/spaces/~612dd45e45cd76006a84071a/pages/17072136/Opensource+Impact+Engine+Framework) is an [Incubation](https://oc.greensoftware.foundation/project-lifecycle.html#incubation) project from the [Open Source Working Group](https://greensoftwarefoundation.atlassian.net/wiki/spaces/~612dd45e45cd76006a84071a/pages/852049/Open+Source+Working+Group) in the [Green Software Foundation](https://greensoftware.foundation/).
+
+**IEF** is a framework to **M**odel, **M**easure, si**M**ulate and **M**onitor the environmental impacts of software
+
+Modern applications are composed of many smaller pieces of software (components) running on many different environments, for example, private cloud, public cloud, bare-metal, virtualized, containerized, mobile, laptops, and desktops.
+
+Every environment requires a different model of measurement, and there is no single solution you can use to calculate the environmental impacts for all components across all environments.      
+
+The friction to measuring software emissions isn't that we need to know how, it's that we run software on many things and each thing has several different ways to measure.
+
+Read the [specification and design docs](https://github.com/Green-Software-Foundation/if-docs) to begin.
+
+
+## Get started
+
+The first thing to understand is that IF is a framework for running model plugins. This means that in order to do some calculations, you need to load some models from some external resource. We provide a [standard library of models](https://github.com/Green-Software-Foundation/if-models) and a repository of [community models](https://github.com/Green-Software-Foundation/if-community-models) to get you started. 
+
+Start by installing some models:
+
+```sh
+yarn add https://github.com/Green-Software-Foundation/if-models
+```
+
+Then create an `impl` file that describes your application (see our docs for a detailed explanation).
+
+Then, run `impact-engine` using the following command:
+
+```sh
+npx ts-node impact-engine.ts --impl <path-to-your-impl-file>
+```
+
+You can also add an optional savepath for your output yaml (if you do not provide one, the output will be printed to the console):
+
+```sh
+npx ts-node impact-engine.ts --impl <path-to-your-impl-file> --ompl <your-savepath>
+```
+
+The `impact-engine` CLI tool will configure and run the models defined in your input `yaml` (`impl`) and return the results as an output `yaml` (`ompl`).
+
+## Video walk-through
+
+Watch this video to learn how to create and run an `impl`.
+
+[![Watch the walk-through video](https://i3.ytimg.com/vi/R-6eDM8AsvY/maxresdefault.jpg)](https://youtu.be/R-6eDM8AsvY)
+
+
+## Run tests
+
+To run the complete set of tests simply run
+
+```sh
+yarn test
+```
+
+To refresh the set of `ompl`s used for validating the output files, run the `scripts/impact-test.sh` bash script (for unix only) as follows:
+
+```sh
+./scripts/impact-test.sh
+```
+
+Then run
+
+```sh
+yarn test
+```

package/build/__mocks__/azure/index.d.ts

@@ -0,0 +1,11 @@
+export declare class MockAzureCredentials {
+}
+export declare class MockMonitorClient {
+    metrics: any;
+    constructor();
+}
+export declare class MockComputeManagementClient {
+    virtualMachines: any;
+    resourceSkus: any;
+    constructor();
+}