-
Notifications
You must be signed in to change notification settings - Fork 2
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
base: main
Are you sure you want to change the base?
Changes from all commits
a638994
fb20c63
9e815ef
7e7a0ff
42bfad5
f3d7b7d
d192453
e687b72
5b7969c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Presumably, yes; there should be some transparency and progress monitoring tools. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
||
[](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. | ||
|
||
 | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah ARM = Azure Resource Management, confusing |
||
|
||
> Note: if you get a timeout -- try a few more requests to give proper time for boot-up. | ||
|
||
 | ||
|
||
> 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. | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing link - or TBD?