Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: create arm templates #1

Draft
wants to merge 9 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 60 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,64 @@
# edgex-endorsement
# EdgeX Endorsement

## Introduction

Code, tools, and documentation for validating and endorsing device profiles written by third parties.
Code, tools, and documentation for validating and endorsing device profiles written by third parties. At a high level you'll need to complete five steps to be eligible for the EdgeX Endorsement Program which will ensure that data provided meets all requirements.

1) Deploy EdgeX using one of the provided cloud templates. Alternatively, you can leverage the latest released compose-file provided here: This ensures a vanilla version of EdgeX is being used without modification to ensure the highest compatibility.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing link - or TBD?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, "Deploy EdgeX" should not be the first step. Your second step is a better first-step candidate.

Second, I argue that we not lead with cloud deployments. Instead, let's be deployment neutral and suggest the two options: a cloud instance or a local docker instance.

2) Compose and deploy your device profile using the Device Profile Modeling tool provided [here](https://www.edgexfoundry.org/tbd). This will ensure the profile is validated and has all required components.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This second-step should be the first step.

  2. It is my understanding that we do not support nor provide tools for composing device profiles. Are we revisiting that decision? Furthermore, it might be unwise to ask the user to now start composing their device profile (presumably a time-consuming affair) just after you had them start the meter on an EdgeX instance!

  3. It my mind, the first step is validating the device profile, which does not require an EdgeX instance and hence, no need to deploy the profile. I am aware, though, that some suggestions include improving upon the built-in validation codebase in Core and utilizing that as part of the EdgeX Endorsement process, so we can start a seperate thread on device profile validation implementation.

I envision two user types and casually refer to them as low-torque/high-revolutions and high-torque/low-revolutions. The former are those who are starting with a nearly blank sheet approach and iterate frequently as they build their device profile. The latter have a nearly complete device profile in hand and need only a few iterations at most to fix the profile.

Copy link
Author

@rsdmike rsdmike Jul 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the plan is to leverage Iotech device profile builder, building one by hand is probably the worst thing we could ask anyone to do and most certainly would be a time consuming affair. This build to me would be deployed as part of step 1 which is why I have it first as a prereq.

3) Run your device locally, configured to point at the cloud instance of the deployed EdgeX to send data to either an MQTT or REST device service.
4) Once deployed, Run the verification script provided to ensure that core-data has been correctly populated with the data that was sent in the previous step.
5) Submit your device profile along with sample data to EdgeX for approval [here](https://www.edgexfoundry.org/tbd). After submitting, you should received a confirmation email that the profile has been submitted. The device profile will then be reviewed by the Certification Working Group, suggest any edits if necessary, and will either approve or deny the device profile submission.


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have some information about what happens after you submit? At least give some indication of the process and timeline and results (email back or what?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably, yes; there should be some transparency and progress monitoring tools.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll throw a dart at the dartboard as to what that process looks like... :D


## 1) Deploy EdgeX

If you want to see how all of EdgeX works - you can leverage your own Azure account and deploy EdgeX to the cloud. This template leverages Azure Container Instances and will deploy a single group called "edgex-example" with 12 services deployed with 2.4 vCPUs allocated (0.2 vCPUs per service) and 6GB of RAM allocated (0.5 GB per service) with an estimated cost of $0.14904 / hour or $3.57696 / day.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If people want to this to run in their own environment vs. Azure - will we allow it? If so, do we send them to our regular docs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My original thought was no...avoid any issue with changes in configuration, customizations of EdgeX, or other potentially not foreseeable changes that could be done locally. But, maybe it doesn't matter if we have verification scripts.


1 container groups * 3600 seconds * 2.4 vCPU * $0.0000135 per vCPU-s = ~$0.11664 / hour

1 container groups * 3600 seconds * 6 GB * $0.0000015 per GB-s = $0.0324 / hour

memory($0.0324) + cpu($0.11664) = $0.14904 / hour
= $3.57696 / day

[![Deploy to Azure](https://aka.ms/deploytoazurebutton)](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Frsdmike%2Fedgex-endorsement%2Farm%2Ftemplates%2Fazure%2Fazuredeploy.json).

Once deployed, the public IP should be provided in the output of the deployment details.

![Screenshot](./images/azure_output_screenshot.png)

A couple different ways to ensure the stack has been successfully deployed is to ensure consul status for each service is healthy by visiting http://[ipaddress]:8500.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe provide links to getting started guide with more details on how to check services when something is not running.

Copy link
Author

@rsdmike rsdmike Jul 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, see this is kinda what I'm thinking we want to avoid with allowing to be run locally. This should be simple -- if it doesnt work, then an issue should be submitted on github saying it the deployment doesn't work. Basically, if ain't all green in consul, stop and let us know. Guiding device service providers to start understanding how to debug EdgeX is a requirement that seems to much to ask to me. "I just wanna pump data in and be compatible"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first time I read "create arm templates," I misread "arm" as in from ARM Holdings.

Yeah ARM = Azure Resource Management, confusing


> Note: if you get a timeout -- try a few more requests to give proper time for boot-up.

![Screenshot](./images/consul_health.png)

> Note: You can safely ignore the 1 error on edgex-redis

## 2) Develop Device Profile

Once you have confirmed that EdgeX is running in the cloud. The next step is to develop a device profile. You can learn about developing device profiles [here](https://docs.edgexfoundry.org/1.2/microservices/device/profile/Ch-DeviceProfile/).

Two different types of device services are supported.
- MQTT
- REST

## 3) Run your Device

If integrating with EdgeX via REST, follow the documentation [here](https://github.com/edgexfoundry/device-rest-go).

If integrate with EdgeX via MQTT, follow the documentation [here](https://docs.edgexfoundry.org/1.2/examples/Ch-ExamplesAddingMQTTDevice/
)

## 4) Run the Verification Script

Once you have your device sending data into EdgeX. Run the verification script.
This script will query EdgeX to ensure that the data you've sent in has successfully been received.

## 5) Submit

Once the verification script has passed. You'll need to submit some sample data that represents the data that your device will be submitting.


Binary file added images/azure_output_screenshot.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/consul_health.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading