Git Product home page Git Product logo

carbon-aware-sdk's Introduction

Join #CarbonHack22

Decarbonize Software. 40K Top Prize.

Carbon Hack 22, the best carbon aware software solution built using the Carbon Aware SDK and API wins $40K with a total prize pool of $90K.

We're running weekly webinars to talk about the hackathon, demo the SDK and API, talk to hackathon participants and answer any questions. To register for the next one click this link 👉 https://grnsft.org/hack22/webinar

For the duration of the hackathon you can try a hosted version of the API with real-data, try it out here 👉 https://grnsft.org/hack22/api

A carbon aware application does more when the electricity is clean, and less when it's dirty. Whether your specialty is machine learning, web, mobile, cloud, IoT or anything in between you can make any type of application carbon aware with the Carbon Aware SDK and API. Review FAQ doc to learn more about the SDK.

You can compete by yourself or join another team if you don't have an idea! Visit our Project Ideas Matchmaking doc where you can find teams to join.

Competition starts on Oct 13 and runs for 3 weeks.

Hackathon ends with a two-minute pitch presentation on Nov 10, judged by global industry leaders from Accenture, Avanade, Boston Consulting Group (BCG), Globant, Goldman Sachs, Intel Corporation, Thoughtworks, and UBS. Hosted by the Green Software Foundation.

If you are convinced already and want to signup to the hackathon register at https://grnsft.org/hack22.

Carbon Aware SDK

You can reduce the carbon footprint of your application by just running things at different times and in different locations. That is because not all electricity is produced in the same way. Most is produced through burning fossil fuels, some is produced using cleaner sources like wind and solar.

When software does more when the electricity is clean and do less when the electricity is dirty, or runs in a location where the energy is cleaner, we call this carbon aware software.

The Carbon Aware SDK helps you build the carbon aware software solutions with the intelligence to use the greenest energy sources. Run them at the greenest time, or in the greenest locations, or both! Capture consistent telemetry and report on your emissions reduction and make informed decisions.

With the Carbon Aware SDK you can build software that chooses to run when the wind is blowing, enable systems to follow the sun, moving around the world to where energy is the greenest, and create tools that give insights and help software innovators to make greener software decisions. All of this helps reduce carbon emissions.

Get started on creating sustainable software innovation for a greener future today!

Getting Started

Head on over to the Getting Started Guide to get up and running.

What is the Carbon Aware SDK?

At its core the Carbon Aware SDK is a WebApi and Command Line Interface (CLI) to assist in building carbon aware software. The functionality across the CLI and WebApi is identical by design.

The WebApi

The WebApi is the preferred deployment within large organisations to centralise management and increase control and auditability, especially in regulated environments. It can be deployed as a container for easy management, and can be deployed alongside an application within a cluster or separately.

WebApi Screenshot

The CLI

The CLI tends to be handy for legacy integration and non-cloud deployments, where a command-line can be used. This tends to be common with legacy DevOps pipelines to drive deployment for integration testing where you can test your deployment in the greenest location.

WebApi Screenshot

Who Is Using the Carbon Aware SDK?

The Carbon Aware SDK is being used by large and small companies around the world. Some of the world’s biggest enterprises and software companies, through to start-ups.

Machine Learning (ML) workloads are a great example of long running compute intensive workloads, that often are also not time critical. By moving these workloads to a different time, the carbon emissions from the ML training can be reduced by up to 15%, and by moving the location of the training this can be reduced even further, at times by up to 50% or more.

What does the SDK/API provide that 3rd party data providers such as WattTime or ElectricityMap do not?

Many of the benefits tend to relate to removing the tight coupling of an application from the 3rd party data source it is using, and allow the application to focus on the sustainability impact it is looking to drive. This abstraction allows for changing of data providers, data provider aggregation, centralised management, auditability and traceability, and more.

Collaborative Effort

The Carbon Aware SDK is a collaborative effort between companies around the world, with the intention of providing a platform that everyone can use. This means the API will be striving towards what solves the highest impact issues with diverse perspectives from these organisation and contributors.

Standardization

Something we are driving with the Carbon Aware SDK is towards standardisation of the interface into these data providers. This ultimately will help to drive SCI calculations in the future, and also helps to drive innovation. The 3rd party API’s do differ, and the results can vary in units, from lbCO2/kWh to gCO2/Wh. The Carbon Aware SDK will take care of all conversions to a standardised gCO2/kWh, which becomes increasingly valuable with aggregated data sources.

Standardisation also helps drive innovation. For example, if a 3rd party develops tools to scale Kubernetes clusters based on emissions, they can build against the Carbon Aware SDK. If you want to use this 3rd party tool, the SDK allows the tool to plug in your choice of data providers, not their choice of data provider. In this way the standardisation drives innovation and flexibility of choice.

The intention is to have other compatible tooling and software that leverages the Carbon Aware SDK to obtain emissions data, while being agnostic to the data provider.

Centralised secret and key management

The ability to manage keys to 3rd party API’s can be centralised with the Carbon Aware API. This means that any changes to keys or rotation can be done in a centralised and controlled manner without exposing the keys to application development teams.

It also can be upgraded across all applications within an organisation when centralised, with new data sources being added without consuming applications to make any changes.

In addition, the need for the Carbon Aware SDK is something that has been identified by some of the largest enterprises when looking to drive innovation within their own organisations by centralising the capability within their business, creating green software engineering practices and providing the API internally across their organisation.

Auditability

Due to the API being centralised, this gives you the ability to audit a controlled environment for when decisions are made. With increasing regulatory need, the ability to prove sustainability actions and impact will need to be from highly trusted sources, and having centralised management provides this capability.

Aggregated Sources

A feature we have in the roadmap is the ability aggregate data sources across multiple providers. Different data providers have different levels of granularity depending on region, and it may be that data provider A is preferred in Japan, while data provider B is preferred in US regions.

Similarly, you may have your own data for your data centres that you would prefer to use for on premises workloads, which you can combine in aggregate with 3rd party data providers.

Is it possible to retrieve energy mix information from the SDK?

Energy mix (the percentages that are from different energy soruces i.e. coal, nuclear, wind, gas, solar, tidal, hydro etc) is not provided in the API to date. This may be a feature we will consider in the future. The SDK provides emissions percentage information only at the moment.

Contributing

The Carbon Aware SDK is open for contribution! Want to contribute? Check out the contribution guide.

Green Software Foundation Project Summary

The Carbon Aware SDK is a project as part of the Green Software Foundation (GSF) and the GSF Open Source Working Group.

Appointments

  • Chair/Project lead - Vaughan Knight (Microsoft)
  • Vice Chair - Szymon Duchniewicz (Avanade)

GSF Project Scope

For developers to build carbon aware software, there is a need for a unified baseline to be implemented. The Carbon Aware Core SDK is a project to build a common core, that is flexible, agnostic, and open, allowing software and systems to build around carbon aware capabilities, and provide the information so those systems themselves become carbon aware.

The Carbon Aware Core API will look to standardise and simplify carbon awareness for developers through a unified API, command line interface, and modular carbon-aware-logic plugin architecture.

carbon-aware-sdk's People

Contributors

aaronrandall avatar akshara-msft avatar bderusha avatar buchananwp avatar danuw avatar dnastrain avatar dylhall avatar gfmatthews avatar github-actions[bot] avatar jawache avatar jenmadiedo avatar juzuluag avatar kanishkt123 avatar microsoft-github-policy-service[bot] avatar nickvilimek avatar plasne avatar pritipath avatar rakker91 avatar seanmcilroy29 avatar srini1978 avatar vamsi12a2 avatar vaughanknight avatar willmish avatar yasuenag avatar yelghali avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

carbon-aware-sdk's Issues

Improve integration test coverage

Description

As a Carbon Aware application developer, I want to know that all the existing codepaths have had robust integration tests to ensure no flows are broken end-to-end when new features are added

Acceptance Criteria

  • Ensure that all external client functions (WebAPi, CLI, and Library) are fully integration tested and code coverage confirms (ignoring non-testable code paths). Example of forecast/batch not having tests.
  • Ensure that integration tests are consistent across the client functions aka same things are tested for all external functions

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Keep packages/lib versions consistent across projects

Description

All projects need to be reviewed to ensure that projects are using the same version of packages or libraries.

Acceptance Criteria

  • Ensure the review process is automated
  • Ensure the pipeline checks to verify that all projects are then updated when a package is updated.
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Tooling and documentation to create the ingestible library package

Description

As a Carbon Aware Application Developer, I want to install the SDK as a C# Library from a package, so that I can use the SDK within my application.

Library Packaging Design

Acceptance Criteria

Tooling

  • Ensure there is a tool identified and available to use for packaging.
  • Verify the package can be signed with a certificate.
  • Verify debug symbols are adding to the package.
  • Ensure a script is available that will build the package from a repository.

Documentation:

  • Document steps on how to generate CarbonAware packages.

  • Document a Getting Started Guide on How to Write a Client/Consumer of the SDK

  • Verify the packaging will install within a C# application or Azure Function

Dependencies

Green-Software-Foundation#182

Task List

  • Create Github Action workflow
  • Test bash scripts on Linux/Unix
  • Test bash scripts on Windows
  • Add docs on how to create packages and consume
  • Modify .csproj files to include/exclude certain projects
  • Create demo gif

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Update EM and WattTime Client Tests to use a real moq for httpClient message handling

Description

As a Carbon Aware application developer, I want a standard moq infrastructure for writing client tests.

See: Green-Software-Foundation#194 (comment)

Acceptance Criteria

  • Remove custom mocks of http class in client tests
  • Client tests use Moq.Protected and have clear path for replicating/adding more tests
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • Remove custom mock of http class in ElectricityMapsClientTest
  • Remove custom mock of http class in WattTimeClientTest
  • Use Moq.Protected to simulate Http Client

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Move CarbonAwareParameters class to CarbonAware package

Description

As a developer in the CarbonAware SDK, I want the CarbonAwareParameters class that is shared by all clients of the SDK to live in the main Carbon Aware project

Acceptance Criteria

  • Move CarbonAwareParameters in to the CarbonAware project
  • Ensure tests pass

Dependencies

Task List

  • Move carbon aware parameters class to carbon aware project
  • Update references in Library, WebAPI and CLI
  • Update unit tests

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[Bug] WattTime password enconding non-ASCII

Description

As a Carbon Aware application developer, I need to be able to encode by WattTime password even with non-ASCII characters

Acceptance Criteria

  • Move to UTF-8 encoding instead of ASCII for credentials

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Improve location files handler when dealing with duplicated keys.

Description

As a Carbon Aware application developer, I want that location source keys don't collide

Acceptance Criteria

  • Avoid missing location definitions to be missed as part of loading the application
  • Avoid location key collisions when loading location definitions from different locations-source json files
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • Load all the locations definitions from all the json files
  • Generate new key if there is key name collision.
  • Add unit test to verify key name renaming.

Improve unit test coverage + style

Description

As a Carbon Aware application developer, I want to know that all the existing codepaths have been unit tested to ensure bugs are caught

Acceptance Criteria

  • Ensure that all external client functions (WebAPi, CLI, and Library) are fully unit tested and code coverage confirms (ignoring non-testable code paths). Example of forecast/batch not having tests.
  • Ensure that the main aggregator and data source functions (which are part of a flow from the client) are fully unit tested and code coverage confirms (ignoring non-testable code paths)
  • Condense redundantly similar tests into single test with multiple test cases (exception throwing, null/edge cases are good ones usually)
  • Ensure complex functions have edge case testing too, not just happy path

Dependencies

Task List

  • Review WebApi tests
  • Review CLI tests
  • Review CA Library tests
  • Review Data Sources tests
  • Open draft PR

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Create a branch strategy to facilitate feedback on the API design

Description

As a consumer of the API, I want to have a single branch to point to so that I can give feedback on the API design

Acceptance Criteria

  • A branch release exists with the API library changes and any other relevant PRs / commits needed to facilitate real-world usage of the C# library (using just WattTime data is okay)
  • Instructions and clear delineation are available so that engineers know when PRs have to be made to both release and to the GSF parent repo

Dependencies

Task List

  • Create release
  • Merge appropriate PRs / commits into release
  • Create / circulate understanding of what criteria necessitate merging into both release and to the GSF repo

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[Epic] Install the Carbon Aware SDK as a Package

Goal

Design and convert the Carbon Aware SDK to be used as a package within code. The goal of the customer is to simplify the hosting of the SDK as the customer does not allow HTTP connections to be opened.

Success Metrics

  • The Carbon Aware SDK can run in a closed network with access to Electricity Map being the only external traffic allowed.
  • The Carbon Aware SDK is not called from an HTTP connection.
  • A script is provided on how to create and publish the package.

Work Items

Design and Specification 📔

Engineering ⚙️

Release Planning

  • Integration tests are complete
  • Demo the feature internally
  • Pull Request created in GSF/dev branch

Allow nullable for CarbonAware.csproj

Description

CarbonAware.csproj is the original project and it does not have the flag set to allow nullable objects.

Acceptance Criteria

  • Ensure that the EnableNullableOjects flag is set in the CarbonAware.csproj
  • Ensure that all warnings that an object is not typed are fixed by adding a type
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Add Emissions Location and Best Contract to the C# Library

Description

As a developer of a carbon-aware application, I want to consume the Emissions Location and Best routes as a C# library so that I can run the SDK within a single application.

Acceptance Criteria

  • Ensure the developer can access the emissions/bylocation function
  • Ensure that the carbon intensity result for a single location is returned to the application when the bylocation function is called
  • Ensure the developer can access the emissions/bylocations function
  • Ensure that the carbon intensity results for multiple locations are returned to the application when the bylocations function is called
  • Ensure the developer can access the emissions/bylocations/best function
  • Ensure that the lowest carbon intensity result for multiple locations is returned to the application when the bylocations/best function is called
  • Unit Tests are completed and code passes tests
  • Documentation and examples are provided for C# Library Emissions

Dependencies

#160
#166

Task List

  • Add GetEmissionsDataAsync path
  • Add GetBestEmissionsDataAsync path
  • Add GetAverageCarbonIntensityBatchAsync path
  • Add Unit Tests
  • Add Library documentation

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Implement Electricity Maps HTTP Client

Description

As a Carbon Aware SDK Developer, I want to login and connect to Electricity Maps API service, so that I can use Electricity Map as a data source.

Acceptance Criteria

  • Verify that the client can pass credentials to Electricity Map API
  • Ensure that the Electricity Maps client can connect to https://api.electricitymap.org endpoints.
  • Ensure that the Electricity Maps API can be called through a proxy [similar to WattTime data source]
  • Ensure that any errors returned from Electricity Maps is forwarded to the consumer layer
  • Unit Tests are completed and code passes tests
  • Ensure Electricity Map client documentation is added.
  • A strategy exists for how and when to update the mappings between API endpoints should Electricity Map update their API at some point in the future (i.e. versioning support)

Dependencies

GSF Backlog Reference
Green-Software-Foundation#71

Task List

  • Implement HTTP client that can handle HTTP requests
  • Enhance HTTP Client Configuration, so credentials can be passed on.
  • Implement Error Handling
  • Implement lookup for Routes supported for HTTP Client.
  • Implement Proxy Service
  • Add unit tests.
  • Add documentation.

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Improve experience for free trial users of Electricity Maps

Description

As a Carbon Aware application developer using the free trial of electricity maps, I want to know what the limitations of the SDK are for me and have as close an experience to a full token user as possible.

Acceptance Criteria

  • Ensure that all the special note about have a free trial token (different header, different token, routes available, connection limits etc.) are documented
  • Ensure that in places when more information can be provided to free trial users (a failure that is unique to those users and not token users), we check and provide the appropriate response.

Dependencies

Task List

  • Update documentation on limitation
  • Add validation for mismatched configuration (token url needs 'auth-token' header versus trial url needs 'X-BLOBR-KEY' header)
  • Add unit tests for validation
  • Add better error messaging at failure point for free trial users

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

ADR-0004: Move/update GettingStarted.md content

User Story

As a carbon aware sdk user, I want all relevant docs to exist in the /docs directory, per the standard set by ADR-0004, so I can have consistent expectations about where to go for content.

Design Goals

  • Find a home for all existing GettingStarted.md content.
  • Understand the difference between GettingStarted and quickstart and make it clearer (or merge if no difference).
  • Markdown-lint compliant

Task List

  • Moving GettingStarted.md (GS) into docs
  • Review GS and quickstart.md (QS) and identify similarities/overlap in content
  • Decide whether GS ans QS should be merged into a single doc or own different spheres (idea: one is architecture focused; one code focused....)
  • Leverage outcome ^^ to also help guide new users on navigating other documentation

Acceptance Criteria

  • GettingStarted.md no longer exists in the root directory
  • User have a clear guide for starting out with the SDK
  • All unique pieces of information from the original GettingStarted.md can be found somewhere in /docs
  • Content touched is markdown-lint compliant

Align `dev` branch with GSF

Description

Microsoft fork has features on dev which have not been contributed back to the GSF, this causes drift and makes it hard to contribute features in the future. We must contribute back everything in shared files on our dev branch to ensure future development is in-line with the parent project. Files unique to the fork can live in a specific commit (6696b8cb)

Acceptance Criteria

  • Microsoft fork can stay current with the GSF main & dev branches without losing functionality

Dependencies

Task List

Prepare PRs for:

  • ADR-0005
  • CLI
  • JSON data source bug fix
  • LocationSource
  • Github Templates

PRs merged for:

  • ADR-0005 (this is not blocking)
  • CLI
  • JSON data source bug fix
  • LocationSource
  • Github Templates

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Pending Features

ADR-0005

Issue: Issue #126 · Green-Software-Foundation
PR: Pull Request #127 · Green-Software-Foundation
MS fork branch: 623/ADR-0005-web-api-stream
Dependencies: None
Status: MERGED! 🎉

CLI

Issue: Issue #131 · Green-Software-Foundation
PR: PR #158
MS fork branch: 162/cli-redesign
Dependencies: CarbonAwareParameters + Mock Refactor (both are now merged)
Status: MERGED! 🎉

Previous branches for reference: 623/cli-redesign-with-dependencies + 623/cli-redesign

JSON data source bug fix

Issue: Issue #155
PR: PR #156
MS fork branch: 162/json-bug-fix
Dependencies:
Status: MERGED! 🎉

LocationSource

Issue: Issue #95
PR: PR #157
MS fork branch: 162/location-source
Dependencies:
Status: MERGED! 🎉

Github Templates

Issue: N/A
PR: N/A
MS fork branch: 162/github-templates-ms
Dependencies: None
Status: Templates merged with larger ms-specific-files commit, ready to go in as first commit when gsf/dev == ms/dev

Create a C# API Contract that exists as a consumer layer for Forecast and Marginal Routes

Description

As a developer of a carbon-aware application, I want to consume the Forecast and Average Carbon Intensity api as c# library so that I can run the SDK within a single application.

SDK as a Library ADR

Acceptance Criteria

  • Ensure the developer can access the emissions/forecasts/current API
  • Ensure that the current forecast result is returned to the application when the emissions/forecasts/current API is called
  • Ensure that developer can access the emissions/average-carbon-intensity API
  • Ensure that the average carbon intensity result is returned to the application when the emissions/average-carbon-intensity API is called
  • Unit Tests are completed and code passes tests
  • Documentation is provided for Forecast API
  • Documentation is provided for Average Carbon Intensity API

Dependencies

The C# API Contract Layer is dependent on the existing CarbonAware.Aggregator.
The acceptance criteria is dependent on one Data Source being available to return a result. This does not need to be Electricity Maps.

Green-Software-Foundation#171

Task List

  • Define namespace for library
  • Define data types that are returned to user
  • Implement IEmissionHandler + EmissionHandler for average
  • Implement IForecastHandler + ForecastHandler for current
  • Add docs + unit tests for forecast handler
  • Add docs + unit tests for emissions handler
  • Add a basic class for wrapping exceptions

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time (2 weeks), but large enough to provide value?

Sample Azure Function App with C# Library

Description

As a SDK consumer, I want to look at an example Azure Function app so I can see how the API would get called in a real-world scenario and learn how to structure my own usage of the API.

Acceptance Criteria

  • Azure Function app that can be loaded and debugged on any machine with dotnet core.
  • No dependencies on Azure or other external services apart from the C# CA-SDK library
  • Demonstrated minimum viable usage of the API
  • Tests demonstrate usage of json data sources as mocks for the real data sources
  • Code demonstrated how to configure credentials for WattTime / ElectricityMap and how to configure the aggregator to point to whichever data source.

Dependencies

Task List

  • Split az func to be for IEmissions and IForecast
  • Integrate into pipeline to build automatically
  • Integrate into pipeline to run
  • Perform emissions requests against az func running.
  • Document any extra vscode packages needed to be able to run func.
  • Review docs to ensure clear about what is local, and what requires azure deployment as an example.

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[Epic] Add Electricity Maps as a Data Source to the Carbon Aware SDK

Goal

Electricity Maps is a third-party API that provides Marginal Carbon Intensity Rates as well as breakdown information on where the Carbon is being generated (nuclear, solar, etc). Electricity Map has consistently been proven to provide more accurate Carbon Intensity rates in Europe.

For the Carbon Aware SDK project involving Electricity Maps, there are two goals

  • Provide another data source to the Carbon Aware SDK so that it can be more widely adopted.
  • Prove that the architecture designed by the CSE team works and can be reused.

Success Metrics

  • Provide the Average Carbon Intensity over the Azure Batch duration using Electricity Maps Data
  • Provide the lowest Forecasted Average Carbon Intensity Rate over the Azure Batch duration using Electricity Maps Data

While not required by the current customer for the MVP, we do expect to implement the batch functionality so that future customers can provide reports on both the Actual and Forecasted data.

Work Items

Design and Specification 📔

Engineering ⚙️

Release Planning

  • Integration tests are complete
  • Demo the feature internally
  • Pull Request created in GSF/dev branch

Azure API Management Sample

User Story

As an Azure APIM user, I want to be able to connect to the carbon aware SDK from my policy to make my implementation carbon aware.

Design Goals

  • Provide an example of how users can integrate the carbon aware SDK into APIM
  • Provide an example policy that uses the carbon aware SDK to make decisions about routing.

Task List

  • Add policy samples
  • Add readme docs

Acceptance Criteria

  • GettingStarted.md no longer exists in the root directory
  • User have a clear guide for starting out with the SDK
  • All unique pieces of information from the original GettingStarted.md can be found somewhere in /docs
  • Content touched is markdown-lint compliant

Improve code related to diagnostics/tracing. Make it consistent across the SDK

User Story

As a carbon aware developer, I can access consistent telemetry libraries and utilities so that I can plumb through telemetry signals throughout the project.

Design Goals

  • minimal maintenance of tracing when new features are added
  • starting a single trace per request/command on "entry"
  • only start additional traces on network "exit" (EG - network request boundaries like EM API calls, etc)

Stretch Goal

Acceptance Criteria

  • No regressions in existing code paths.
  • Only one trace activity is created per request from "entry" to "exit"
  • A new trace activity is created on "exiting" network requests
  • Update documentation to reflect any changes to the operator experience (if any)

Update Data Source Configuration to allow Applications to use Multiple Data Sources

Description

As a Carbon Aware Application User, I want to use different data sources for different interfaces of the Carbon Aware SDK, so that I can use all the functionality of the SDK even if my chosen data source does not implement the full SDK functionality.

Data Source Configuration ADR

Acceptance Criteria

  • Ensure that the changes to the configuration allow an API call to WattTime and the expected result is returned without errors.
  • Verify that the changes to the configuration allow the JSON data source to be used, and the expected result is returned without errors.
  • Ensure that a carbon aware application can use one data source for Emissions and one data source for Forecast (example: JSON for emissions data, and WattTime for forecast data)
  • Unit Tests are completed and code passes tests
  • Documentation is provided that details the configuration scheme and provides an example

Dependencies

The Data Source Configuration is dependent on Decoupling the Interfaces

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Update Data Source Configuration to account for Unique Parameters

Description

As a Carbon Aware Data Source Developer, I want to allow for configuration of parameters that are specific to my data source, so that the data from the data source can be returned as the carbon aware user would like.

Data Source Configuration ADR

Acceptance Criteria

  • Ensure that the data source configuration matches the schema proposed in Data Source Configuration ADR
  • Ensure that the changes to the configuration allow the WattTime data source to be configured and the expected result is returned without errors.
  • Ensure that the changes to the configuration allow the JSON data source to be configured and the expected result is returned without errors.
  • Verify that all data source-specific configuration values are contained in the "Configurations" object.
  • Verify that each data source configuration can have its own unique configurable values.
  • Verify that every data source configuration declares a "Type".
  • Verify that an interface which references a key in the "Configurations" object is used for that interface.
  • Verify that an interface which references a key which does not exist in the "Configurations" object throws an error with a clear, actionable message as early as possible.
  • Unit Tests are completed and code passes tests
  • Documentation is provided that details the configuration scheme and provides an example
  • Data Source configuration documentation exists in /docs/configuration.md
  • Data Source configuration references in /GettingStarted.md link to the relevant /docs/configuration.md section and do not duplicate content from that "source of truth"

Dependencies

The Data Source Configuration is dependent on Decoupling the Interfaces
Green-Software-Foundation#172

Open Questions

  • Should configuration "Type" be the full namespace of the data source?
    • For right now, no. Using the "short name" is fine.
  • Should we support same-data source/different config scenarios?

Task List

  • CarbonAwareVars config class -> DataSources config class
  • Implement the variables for interfaces, configurations, and mapping them together ^
  • Json data source config should be fully contained in a single config class
  • WattTime data source config should also be fully contained (will need move Client config around) ^
  • ServiceCollectionsExtensions updated to register configurations by interface value -> configurations key object && "Type"
  • ServiceCollectionsExtensions updated to register data sources as defined in the config
  • Documentation updates

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Migrate Carbon Aware WebApi to consume CA library

Description

As a Carbon Aware Developer, I want to have the CA WebAPI consumer layer use the Carbon Aware Library so that changes can be made in a single place: the CA Library.

Acceptance Criteria

  • Ensure that the WebAPI consumer layer routes all requests through the Carbon Aware Library.
  • Unit Tests are completed, and the code passes tests
  • Update Documentation, including Architecture diagrams, if needed

Dependencies

Task List

  • List of punch list) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable/testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Documentation for Selecting Data Source based on Functionality

User Story

As a carbon aware developer, I know what functionality/routes are available given the different data sources and any special considerations when switching between the two

Design Goals

  • Clearly note which routes are supported by each data source
  • Note which data sources may be best for particular situations
  • Note special considerations one data source may have over the other

Acceptance Criteria

  • New readme added to docs folder

Add PS scripts for create/add GSF package

Currently there are only bash scripts available under scripts/package and it limits the scope of integration for a Windows user.

Description

As a Carbon Aware application developer using Windows, I would like powershell script equivalents of the bash scripts available under scripts/package so I can run these scripts directly in my environment.

Acceptance Criteria

  • Create add-packages.ps and create-packages.ps powershell scripts
  • Ensure that scripts run as intended on windows machines.

Dependencies

Task List

  • Write powershell scripts
  • Make sure they pass

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Remove dead code paths

User Story

In order to improve the maintainability and readability of the codebase, unused code paths need to be removed.

Acceptance Criteria

  • No regressions in existing code paths.
  • CarbonAware.Config namespace and corresponding files are removed.
  • Unused interfaces in CarbonAware.Interfaces are removed.
  • CarbonAwareCore is removed.
  • CarbonAware.Plugins.BasicJsonPlugin project is removed.
  • CarbonAware.WebAPI/src/plugins directory is removed.
  • CarbonAware.WebAPI/src/carbon-aware.json config file is removed.

ElectricityMapsDataSource Implementation: Forecasted Emissions

Description

As a Carbon Aware Application Developer, I want to get the optimal Forecasted average carbon intensity rate from the current 24-hour forecast using Electricity Maps data, so that I can schedule my Azure Batch job to run at an optimal, or green, time period and/or location.

emissions/forecast/current API documentation

Acceptance Criteria

  • Verify that if the optimal forecast for a single location is requested, then the results return Electricity Maps optimal forecast rate and time for that location
  • Verify that if the optimal forecast for multiple locations is requested, then the results return Electricity Maps optimal forecast rate and time for each location
  • Verify that if the optimal forecast within a start and end time is requested for a single location, then the results return Electricity Maps optimal forecast rate and time for that location where the optimal time is within the start and end times.
  • Verify that if the optimal forecast within a start and end time is requested for multiple locations, then the results return Electricity Maps optimal forecast rate and time for each location where the optimal time is within the start and end times.
  • Ensure that if the forecast request contains the compute duration, then optimal average carbon intensity rate is calculated for the duration requested
  • Ensure that if the forecast request does not contain the compute duration, then optimal average carbon intensity rate is calculated from a single forecast data point
  • Ensure that any errors returned from Electricity Maps is forwarded to the consumer layer
  • Ensure that an error message is returned that informs the the user they are attempting to access functionality that will not work with a Free Trial subscription
  • Unit Tests are completed and code passes tests
  • Ensure that Forecasted Emissions Integration Tests includes Electricity Maps data source
  • Ensure Electricity Map data source documentation is added.
  • Ensure Documentation is added that details what forecast functionality works with a free trial and what needs a paid subscription

Dependencies

#179

GSF Backlog Reference

[Feature Contribution]: electricityMap Plugin

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Clear access boundaries throughout SDK

Description

As a Carbon Aware application developer, I need to have clear access boundaries throughout the SDK, so that I am required to learn and implement the exposed classes.

SDK as a C# Client Library

Acceptance Criteria

  • Ensure that only the public classes are available to the user within the SDK

Verify that the following WebAPI routes can be executed and return the expected results:

Verify that the that following CLI routes can be executed and return the expected results:

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Move WattTimeClient into WattTime project directory

Description

WattTime Client was created as a separate project from the WattTime DataSource project. As we have moved forward with the SDK, the WattTime data source is tightly integrated into the Client.

Acceptance Criteria

  • Ensure the WattTime Client project is located in the WattTime directory.
  • Ensure all references to the WattTime Client project are updated
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Enhance packaging.md to include how to run, build and consume the ConsoleApp using GSF.CarbonAware library.

Contact Details

[email protected]

What happened?

The ConsoleApp sample does not compile right out of the box. I would expect it to compile and guide to how to configure

client

WebAPI (Default)

Relevant log output

C:\code\carbon-aware-sdk\samples\lib-integration\ConsoleApp> dotnet run
C:\code\carbon-aware-sdk\samples\lib-integration\ConsoleApp\Program.cs(1,7): error CS0246: The type or namespace name '
GSF' could not be found (are you missing a using directive or an assembly reference?) [C:\code\carbon-aware-sdk\samples
\lib-integration\ConsoleApp\ConsoleApp.csproj]
C:\code\carbon-aware-sdk\samples\lib-integration\ConsoleApp\Program.cs(2,7): error CS0246: The type or namespace name '
GSF' could not be found (are you missing a using directive or an assembly reference?) [C:\code\carbon-aware-sdk\samples
\lib-integration\ConsoleApp\ConsoleApp.csproj]
C:\code\carbon-aware-sdk\samples\lib-integration\ConsoleApp\Program.cs(3,7): error CS0246: The type or namespace name '
GSF' could not be found (are you missing a using directive or an assembly reference?) [C:\code\carbon-aware-sdk\samples
\lib-integration\ConsoleApp\ConsoleApp.csproj]

The build failed. Fix the build errors and run again.

Code of Conduct

  • I agree to follow this project's Code of Conduct

The Aggregators are dead, long live the Handlers

Description

In order to improve the maintainability and readability of the codebase, I want to delete the Aggregators project and any references to it from the Consumers (WebAPI and CLI). The pre work for this is done as part of #243 where the business logic present in the Aggregators was migrated to Handlers.

Acceptance Criteria

  • No references to Aggregators exist from WebApi & CLI.
  • Aggregator project is deleted
  • Unit Tests are completed, and the code passes tests
  • Documentation is updated, including Architecture diagrams, if needed

Dependencies

Task List

  • List of tasks (punch list) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria are verifiable/testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[Design] : Add Electricity Maps as a Data Source to the Carbon Aware SDK

Description

As Carbon Aware SDK user, I would like use the Electricity Maps API as a data source, so that I can get the average marginal carbon intensity rates and the lowest forecasted carbon intensity rate from Electricity Maps.

Acceptance Criteria

  • Design provides specifications on how to add Electricity Maps as a data source to the SDK with the same or as close to functionality as the WattTime data source
  • Design identifies any changes that are needed due to Electricity Map differences.
  • Final architectural decisions proposed in an Architectural Decision Record log

Dependencies

The implementation is dependent on Electricity Map API functionality.

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Engineering team understands acceptance criteria
  • External / 3rd Party dependencies identified

Tasks

  • Create shared word document to draft early designs

  • Design Area: ElectricityMapsDataSource project @pritipath

  • Design Area: ICarbonIntensityDataSource interface @bderusha

  • Design Area: Config @pritipath

  • Design Area: Integration Testing @bderusha @pritipath

  • Design Area: Telemetry & Logging

  • Design Area: ErrorHandling

  • Update design doc with: @pritipath

    • Estimates for the proposals that we want to move forward
    • Proposals organized by priority & dependency
  • Combine with library proposals. @bderusha

  • Determine global priority @bderusha

  • Create ADRs from joint documents.

Design Area: ElectricityMapsDataSource project

  • Handle auth (Ask A-team for credentials when ready)
  • Understand if EM can support all existing interface methods, and what "work" it will take to do so.
  • Understand what additional EM functionality we cannot expose with the current interface.
  • Would like to have a "separate" EMclient that lives within the EMDataSource project (rather than outside of it like WattTimeClient)

How Should We Estimate Work

Estimates include anything which would be required by our team to merge the feature.
Estimate Unit: sprints (2 people for 2 weeks)

ADR-0004: Add markdown linter

User Story

As a carbon aware sdk contributor, I want to know when my markdown files do not meet the standard set by ADR-0004 so I can fix them.

Design Goals

  • Run markdown-lint on all PRs via GithubActions
  • Do not make running the linter contingent upon fixing all existing violations
  • Ability to customize linting rules and use those rules both in CI and local development

Stretch Goal

  • Ability to auto-fix violations in some manner

Acceptance Criteria

  • markdown-linter runs against PRs
  • markdown-linter merging will not block existing PRs

Implementation Notes

Add Location lookup to API SDK, WebApi, CLI.

Adding reference to an existing GSF issue Green-Software-Foundation#175

Description

As a Carbon Aware application developer, I want to list all the locations definitions as part of an WebApi endpoint, cli command and GSF.CarbonAware handler.

Acceptance Criteria

  • List all the location instances loaded from the json files definitions
  • Be able to use WebApi, CLI and SDK to list all locations entries.
  • Unit Tests are completed and code passes tests

Dependencies

Task List

  • Enhance WebApi to add new route /locations
  • Enhance CLI commands with new command locations
  • Enhance GSF.CarbonAware SDK to include new Locations handler.
  • Add Unit tests
  • Add Integrations tests
  • Update documentation

Create a Parameter Builder class

Description

As a Carbon Aware SDK Developer, I want to use parameters that are specific to the interface I am adding to the SDK, so that I do not need to understand how the SDK aggregators are called.

SDK as a Library ADR

Acceptance Criteria

  • Verify that the consumer cannot access and use the parameter builder
  • Ensure that when parameters are used in an API call, the expected results are returned.
  • Unit Tests are completed and code passes tests
  • Documentation is provided for the SDK developers

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Add Forecast by Date to C# Library Contract

Description

As a developer of a carbon-aware application, I want to consume the Forecast by Date as a C# library so that I can run the SDK within a single application.

Note: Past Forecasts are not available in Electricity Maps. Testing will need to occur with WattTime.

Acceptance Criteria

  • Ensure the developer can access the getCarbonIntensityForecastAsync Data Source function
  • Ensure that the forecast response is returned to the application when the function is called with past dates
  • Unit Tests are completed and the code passes tests
  • Documentation and examples are provided for C# Library Forecast

Dependencies

#160
#166

Task List

  • Add GetForecastByDateAsync() to IForecastHandler
  • Implement GetForecastByDateAsync() in ForecastHandler
  • Add unit tests
  • Add documentation updates

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Electricity Maps Data Source Implementation for Location and Batch

Description

As a Carbon Aware Application Developer, I want to get the actual average carbon intensity rate for by locations and in batches using Electricity Maps data, so that I can get the Average Marginal Carbon Intensity rate for an Azure Batch job.

Acceptance Criteria

  • Ensure that if the configuration is set to use Electricity Maps for emissions, the results for emissions/bylocation return Electricity Maps' average carbon intensity rate for that location and time period
  • Ensure that if the configuration is set to use Electricity Maps for emissions, the results emissions/bylocations return Electricity Maps' average carbon intensity rate for all locations and time period
  • Ensure that if the configuration is set to use Electricity Maps for emissions, the results emissions/bylocations/best return Electricity Maps' lowest average carbon intensity rate for all locations and time period
  • Ensure that if the configuration is set to use Electricity Maps for emissions, the results emissions/average-carbon-intensity/batch return Electricity Maps' lowest average carbon intensity rate for all locations and time periods
  • Ensure that the CLI emissions route return Electricity Maps data for the location and best flags.
  • Ensure that an error is returned that lets the user know their subscription does not have access to the route or zone and to contact Electricity Maps for more information.
  • Ensure that if the custom parameters are not set, then no values are sent to Electricity Map for emissionFactorType or disableEstimations
  • If a custom parameter value for emissionFactorType is not 'direct' or 'lifecycle' the value is sent to Electricity Maps, and the error is handled by Electricity Maps and forwarded to the consumer layer.
  • Unit Tests are completed and code passes tests
  • Ensure documentation is updated with Electricity Maps limitations and custom parameters for the bylocations, best, and batch endpoints
  • Ensure documentation explains the limitations with Electricity Maps historical forecasts.

Dependencies

#174

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Documenting Dynamic Data Source Registration

Description

As a Carbon Aware application developer, I would like to decouple the data sources from the SDK into their own nuget packages and create a mechanism to allow auto discovery and dynamic registration. This will allow for new data sources to be plugged in with minimum configuration and dependency on the existing code base.

Acceptance Criteria

Create a document that defines -

  • High level approach
  • Benefits of doing this
  • Level of effort required and the risks

Dependencies

Task List

  • List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Decouple the IEmissionsDataSource and IForecastDataSource Interface

Description

As a Carbon Aware Data Source developer, I want to add new data sources that may not have all current SDK functionality - including data sources that have only Emissions data but not Forecast data, so I can plug the data source into the SDK without having to throw a NotImplementedException for functionality that does not exist in the data source.

Data Source Interfaces ADR

Acceptance Criteria

  • Ensure that the IEmissionsDataSource interface can be implemented by a data source developer without implementing the IForecastDataSource interface
  • Ensure that the IForecastDataSource interface can be implemented by a data source developer without implementing the IEmissionsDataSource interface
  • Unit Tests are completed and code passes tests

Verify that the following WebAPI routes can be executed and return the expected results:

Verify that the that following CLI routes can be executed and return the expected results:

Dependencies

Green-Software-Foundation#170

Task List

  • Create IEmissionsDataSource, NullEmissionsDataSource, EmissionsAggregator + Tests, Updates Consumers @bderusha
  • Create IForecastDataSource, NullForecastDataSource, ForecastAggregator + Tests, Updates Consumers @pritipath
  • JSON data source config changes
  • WattTime data source config changes
  • Update default config to use NullDataSources
  • clean up step of removing unused refactored code.
    POSSIBLE PR AT THIS POINT
  • Split config into two data source
  • require that AT LEAST ONE data source is configured
  • remove forecasting methods and interface from JSON
  • Update documentation for configuring data sources
    CREATE FINAL PR

Working agreement to delete at little as possible, and just c+p to new classes
Need to document for each other if and when we change any ported code.

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

ElectricityMapsDataSource Implementation: Measure Emissions

Description

As a Carbon Aware Application Developer, I want to get the actual average carbon intensity rate using Electricity Maps data, so that I can that I can get the Average Marginal Carbon Intensity rate for an Azure Batch job.

emissions/average-carbon-intensity API documentation

Acceptance Criteria

  • Ensure that if the configuration is set to use Electricity Maps for emissions, then the results return Electricity Maps' average carbon intensity rate for that location and time period
  • Ensure that an error is returned that lets the user know their subscription does not have access to the past range route if the subscription does not have access and the time period is greater than 24 hours in the past and to contact Electricity Maps for more information.
  • Ensure that an error is returned that lets the user know their subscription does not have access to the route or zone and to contact Electricity Maps for more information.
  • Ensure that if the custom config are values of emissionFactorType and disableEstimations are set, then the values are sent to Electricity Map for emissionFactorType or disableEstimations
  • Ensure that if the custom config value are not set, then no values are sent to Electricity Map for emissionFactorType or disableEstimations
  • If a custom config value for emissionFactorType is not 'direct' or 'lifecycle' the value is sent to Electricity Maps, and the error is handled by Electricity Maps and forwarded to the consumer layer.
  • Ensure that an error message is returned that informs the the user they are attempting to access functionality that will not work with a Free Trial subscription
  • Unit Tests are completed and code passes tests
  • Ensure documentation is updated with Electricity Maps limitations and custom parameters.
  • Ensure Documentation is added that details what forecast functionality works with a free trial and what needs a paid subscription

Dependencies

#167

GSF Backlog Reference

[Feature Contribution]: electricityMap Plugin

Task List

  • List of tasks (punch list) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria is verifiable / testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Migrate Carbon Aware CLI to consume CA library

Description

As a Carbon Aware Developer, I want to have the CA CLI consumer layer use the Carbon Aware Library so that changes can be made in a single place: the CA Library.

Acceptance Criteria

  • Ensure that the CLI consumer layer routes all requests through the Carbon Aware Library.
  • Unit Tests are completed, and the code passes tests
  • Update Documentation, including Architecture diagrams, if needed

Dependencies

Task List

  • List of tasks (punch list) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria are verifiable/testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[Design] Convert Carbon Aware SDK into a Library

Description

As a Carbon Aware Developer, I need to use the Carbon Aware SDK as a library so that I can access the SDK without opening and HTTP connection.

Acceptance Criteria

  • Design needs to consider how to support the same .NET versions as Azure Functions 4.0
  • Design needs to consider how to expose the SDK API routes as a library and while keeping the Aggregator functionality hidden to the user.
  • Design needs to satisfy supporting multiple languages for error messages within the package
  • Design needs to consider how to work with Config Files within the code as well as ensuring the config files are installed and uninstalled with the package
  • Designed needs to consider allowing consumers to step into the code while debugging
  • Design needs to consider package versioning
  • Final architectural decisions proposed in an Architectural Decision Record log

Out of Scope

We will be providing guidance on how to publish the SDK as a package, but we will not be publishing the package.

Dependencies

The customer is considering using the library as part of an Azure Function, so there is a dependency to meet the requirements of Azure Functions.

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Engineering team understands acceptance criteria
  • External / 3rd Party dependencies identified

Tasks

  • Add Library section
    • Goals
    • Non Goals
    • Proposed design
      • Short term
      • Long term
  • Add Packaging section
    • Goals
    • Non Goals
    • Proposed Design
  • Write ADR
    • SDK as a C# client library ADR PR 153

Migrate Handlers in CA library to directly consume the data sources (remove dependency on Aggregators)

Description

As a Carbon Aware Developer, I want the datasource handlers (EmissionHander, ForecastHandler) to directly call the datasource and remove the overhead of having Aggregators in between so that the code is cleaner and extensible.
This would prevent from creating a new Aggregator layer every time a new data source interface is created.

Acceptance Criteria

  • Ensure that the CA library consumes the Datasources directly.
  • Remove reference to the Aggregator project
  • Mark Aggregator methods with 'deprecated' flag
  • Unit Tests are completed, and the code passes tests
  • Update Documentation, including Architecture diagrams, if needed

Dependencies

Task List

  • List of tasks (punch list) needed to complete the user story

Sprint-Ready Checklist

  • Acceptance criteria defined
  • Acceptance criteria are verifiable/testable
  • External / 3rd Party dependencies identified
  • Engineering team understands acceptance criteria
  • Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.