feat: create arm templates #1

rsdmike · 2020-06-08T23:22:57Z

Provide ARM Template for EdgeX using Azure Container Instances

Signed-off-by:` Mike [email protected]

Signed-off-by: Mike <[email protected]>

rsdmike · 2020-07-01T07:14:57Z

@Dunstable @jpwhitemn Please take a look when you have a moment

jpwhitemn

@rsdmike - Mike this is a really good start to outlining our endorsement program. I think it lays out each of the areas where we need to start to put together the program and figure out the details of each part - if you will a roadmap.
This document assumes that the reader probably has a lot of EdgeX experience. I think we'll eventually need to reference more of the documentation here (especially as we strengthen the docs) but also have some documents some where that better outline the program and help take people through these steps in more detail. But its a good crawl step and once we have the links available, I would approve this as a start.

README.md

jpwhitemn · 2020-07-01T13:13:18Z

README.md

-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 required components. 
+
+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.


missing link - or TBD?

jpwhitemn · 2020-07-01T13:15:40Z

README.md

+3) 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.
+4) Submit your device profile along with sample data to EdgeX for approval [here](https://www.edgexfoundry.org/tbd).
+
+


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?).

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

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

README.md

jpwhitemn · 2020-07-01T13:19:05Z

README.md

+
+## 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. 


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?

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.

jpwhitemn · 2020-07-01T13:49:13Z

README.md

+
+![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. 


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

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"

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

Yeah ARM = Azure Resource Management, confusing

Dunstable · 2020-07-02T17:38:35Z

README.md


 ## 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 required components. 


Code, tools, and documentation for validating and endorsing device profiles written by third parties.

This first sentence should not be part of your proposal; it doesn't fit. In the long-term, this sentence will expand to

A tl;dr overview of the EdgeX Endorsement program with links [1] to where one can dive in deeper

An overview of what's contained in this repo with internal links to other README.md/documentation files for more detailed information.

[1] The EdgeX Endorsement program will most likely be fully described on the EdgeX Foundry.org website with some personality-oriented content on docs.edgexfoundry.org.

Ok, makes sense. Until we do I think we'll leave it since we have nothing to link to at this point.

README.md

Dunstable · 2020-07-02T17:51:21Z

README.md

-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 required components. 
+
+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.


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.

Dunstable · 2020-07-02T18:11:37Z

README.md

+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 required components. 
+
+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.
+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.


This second-step should be the first step.

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!

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.

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.

Dunstable · 2020-07-02T18:27:45Z

README.md

+
+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.
+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.
+2) 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.


Technically, this is your third step, not a second! 😄

This reminds me that we should provide a pre-requisites lists that would list, like, having a device with the ability to send (at least mocked/staged) data.

[Thinking out loud here] There is also a need for a paragraph that provides an overview/transparency of endorsement process implementation. A diagram here would be helpful.

[Further thinking out loud here] I'm wondering if we need to walk the user through this step as there is a lot of hand-waving over some heavy lifts:

Deploying the device profile to the appropriate device service

Configuring the appropriate device service with the device configuration

How to find needed data from one's EdgeX instance that is needed for the device's configuration.

Yes I like this, pre reqs would be good -- outline things to be aware of. Yes these are the details I need help with :)

Dunstable · 2020-07-02T18:37:00Z

README.md

+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.
+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.
+2) 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.
+3) 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.


So, we went from "Device Profile Modeling tool" in your step 2 to a "script" in this step 3 (technically, 4).

I need to think about what this script would do aside from being a JSON pretty-printer. It can see the logic in there being a verification step, but, I'm not seeing how we can help here. Are you imagining, say, an instrumented device service that logs the data it receives and an app services configurable that extracts the presumably same data from Core Data and a script that compares the two?

I'm imagining a script that inputs the sample data -- the same data that gets sent to the device service -- and compares it to a core data database query to inspect that the data is all there, properly formatted, and maybe check other things like metadata to ensure that things are registered and described properly.

Yes step 2 is about building the profile, step 4 is about ensuring that the data you sent is properly ingested and properly described.

Dunstable · 2020-07-02T18:38:24Z

README.md

+3) 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.
+4) Submit your device profile along with sample data to EdgeX for approval [here](https://www.edgexfoundry.org/tbd).
+
+


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

Dunstable · 2020-07-02T18:43:16Z

README.md

+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.
+2) 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.
+3) 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.
+4) Submit your device profile along with sample data to EdgeX for approval [here](https://www.edgexfoundry.org/tbd).


Do we want the device profile? Or are the words "device profile" placeholders for some yet to be defined evidentiary data proving a specific test was run.

If we accept device profiles, are we doing anything with them?

There might be some resistance to providing device profiles as they may only be made available when appropriate licensing agreements (e.g. money has been exchanged) are in place.

to me the device profile submissions is a link to the github repo they are hosted in -- which in turn, once verified -- will land on the edgex endorsement webpage and be linked to.

Dunstable · 2020-07-02T18:48:02Z

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

Signed-off-by: Mike <[email protected]>

rsdmike added 8 commits June 8, 2020 16:22

feat: create arm templates

a638994

Signed-off-by: Mike <[email protected]>

docs: endorsement

fb20c63

Signed-off-by: Mike <[email protected]>

test link

9e815ef

Signed-off-by: Mike <[email protected]>

update to geneva

7e7a0ff

Signed-off-by: Mike <[email protected]>

remove double slash

42bfad5

Signed-off-by: Mike <[email protected]>

fix rest image

f3d7b7d

Signed-off-by: Mike <[email protected]>

docs: remove 8400

d192453

Signed-off-by: Mike <[email protected]>

docs: endorsement

e687b72

Signed-off-by: Mike <[email protected]>

rsdmike marked this pull request as draft July 1, 2020 07:15

jpwhitemn reviewed Jul 1, 2020

View reviewed changes

Dunstable reviewed Jul 2, 2020

View reviewed changes

docs: PR feedback

5b7969c

Signed-off-by: Mike <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: create arm templates #1

feat: create arm templates #1

rsdmike commented Jun 8, 2020 •

edited

Loading

rsdmike commented Jul 1, 2020

jpwhitemn left a comment

jpwhitemn Jul 1, 2020

jpwhitemn Jul 1, 2020

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020

jpwhitemn Jul 1, 2020

rsdmike Jul 22, 2020

jpwhitemn Jul 1, 2020

rsdmike Jul 22, 2020 •

edited

Loading

rsdmike Jul 22, 2020

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020

Dunstable Jul 2, 2020

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020 •

edited

Loading

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020

rsdmike Jul 22, 2020

Dunstable Jul 2, 2020

Dunstable Jul 2, 2020

rsdmike Jul 22, 2020

Dunstable commented Jul 2, 2020

		3) 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.
		4) Submit your device profile along with sample data to EdgeX for approval [here](https://www.edgexfoundry.org/tbd).


		## 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.


		![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.

feat: create arm templates #1

Are you sure you want to change the base?

feat: create arm templates #1

Conversation

rsdmike commented Jun 8, 2020 • edited Loading

rsdmike commented Jul 1, 2020

jpwhitemn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsdmike Jul 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsdmike Jul 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Dunstable commented Jul 2, 2020

rsdmike commented Jun 8, 2020 •

edited

Loading

rsdmike Jul 22, 2020 •

edited

Loading

rsdmike Jul 22, 2020 •

edited

Loading