Skip to end of metadata
Go to start of metadata

Meeting Time and Conference information

Meeting Time:  3rd Monday of each month at 1pm EST as needed (if there are no agenda items, the meeting is cancelled)

EdgeX Working Group 2 is inviting you to a scheduled Zoom meeting.

Topic: EdgeX - Monthly Architects Meeting
Time: Nov 30 2020 10:00 AM Pacific Time (US and Canada)
Every month on the Third Mon, until Nov 18, 2024, 50 occurrence(s)

Please download and import the following iCalendar (.ics) files to your calendar system.

Join Zoom Meeting

Meeting ID: 353 955 907
Passcode: 150365
One tap mobile
+16699006833,,353955907# US (San Jose)
+12532158782,,353955907# US (Tacoma)

Dial by your location
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
+1 778 907 2071 Canada
+1 204 272 7920 Canada
+1 438 809 7799 Canada
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
855 703 8985 Canada Toll-free
Meeting ID: 353 955 907
Find your local number:

Meeting Agenda/Minutes

March 28, 2022:  Meeting Notes; Meeting Recording

Feb 28, 2022: Meeting Notes; Meeting Recording

Jan 24, 2022: Meeting Minutes; Meeting Recording

Dec 13, 2021:  Meeting Minutes; Meeting Recording

Nov 15, 2021:  Meeting cancelled

Oct 18, 2021:  Meeting Minutes; Meeting Recording

Sept 20, 2021:  Meeting Minutes; Meeting Recording

May 17, 2021:  Meeting Minutes; Meeting Recording

Apr 19, 2021:  Meeting Minutes; Meeting Recording

Mar 15, 2021:  Meeting Minutes; Meeting Recording

Feb 16, 2021:  Meeting Minutes; Meeting Recording

Architects Meeting - EdgeX Microservice Authentication.pptx.pdf (Bryon's presentation)

Jan 26, 2021: Meeting Minutes; Meeting Recording

Nov 30, 2020:  Meeting Minutes; Meeting Recording

Sept 21, 2020:  Meeting Minutes; Meeting Recording; Adopter Series Requirements Summary

Aug 20, 2020:  Meeting Minutes; Meeting Recording

July 20, 2020: Meeting Minutes; Meeting Recording

June 30, 2020 (extra meeting to address growing number of issues): Meeting Minutes; Meeting Recording

Tony's slide deck on commit messages

Jun 15, 2020:  Meeting Minutes; Meeting Recording

May 18, 2020:  Meeting Minutes; Meeting Recording (Password: 1k&I$62S)

April 20, 2020: Meeting Minutes; Meeting Recording (Password: 5W?vM=#X)

Mar 16, 2020 (special long session): Meeting Minutes; Trevor Conn's V2 API issue notes; Meeting Recording

Mar 3, 2020: Meeting Minutes; Meeting Recording (API V2 special session)

Feb 18, 2020:  Meeting Minutes; Meeting Recording

Jan 27, 2020:  Meeting Minutes; Meeting Recording

Dec 16:  Meeting Minutes; Meeting Recording

Dec 4: Meeting Minutes; Meeting Recording

Nov 18: Meeting Minutes; Meeting Recording

Open Topics

  • High - Service List ADR review (with need for some implementation / design details)
    • Jim to get with Bryon and have him cover his ADR ( in the next Security WG as this may make this ADR moot
    • All EdgeX architects are asked to review the following in advance of the next Monthly Architects meeting so this ADR can be dispositioned:
      • Service List ADR
      • Registry ADR (already approved)
      • The getAllServiceEndpoints query on the registry API to be able to query for all services
    • Architects are requested to put comments in the service list ADR after review of above
    • At the next Monthly Architect’s meeting (Oct 18), we’ll make a decision as to whether the ADR is still needed, what to update, and create a more detailed design (including secure and non-secure) if it is still needed.
    • Rejected per 10/18/21 meeting
  • High - Metrics ADR review
    • The ADR needs to be updated to include (Jim White task)
      • Recent changes per Ireland (state of SMA, 0MQ, etc.)
      • Change the configuration around message bus to use the common message bus info (message protocol, host, port, etc.)
    • The go-metrics library needs to be explored (Jim to do). This go library would probably be the means to implement this feature.  Explore the library for:
      • How it manages the telemetry data (persistence, in memory, database, etc.)
      • Does it offer a query API (in order to easily support the ADR suggested REST API)
      • What does the go-metrics package do so that its features can become requirements for C side
      • Can the metric/telemetry count be reset if needed? Does this happen whenever it posts to the message bus?  How would this work for REST?
    • Are metrics collected on a timeframe (“timed”) and can the timeframe be reset? Ex:  collect the number of requests on the API and have a way to reset that count back to zero?  Are any of the metrics “static” – meaning they are never reset?
  • High - Unit of Measure ADR review
    • Standardizing units of measure
  • High - ADR on device profile changes
  • High - new ADR requests per planning meeting
    • validation of device protocol properties (device services)
    • micro service authentication (security)
  • Med - Replacing poor 3rd party libs - per Jakarta planning meeting (6/21)
    • Relook policies for 3rd party libs and how to evaluate, especially for device services. Also, should we start to fork these “immature” libraries
  • Low - per Core WG meeting of 4/22/21 and Jakarta Planning Meeting (6/21) - how much info should be put in errors and log messages.
    • There is a concern about putting to much information in from those familiar with commercial products
    • Temporary decision was to provide enough so that someone could debug the problem with the information provided and not to be concerned with exposing intellectual property since everything is open source.
    • Per planning meeting:  need a survey to address but don't believe we have an issue
    • Potentially is an issue in defining what is Error/Info/Warning
  • Low - Revisit combine core services at least at all executables in one image
    • Release would be easier but image would be bigger with more complex compose files
    • Per Core WG of 2/18/21 - is it at least worth exploring the combination of Core Metadata and Core Command since the two have to share so much data?
    • Core command is just a proxy service today, but reasons for having a separate service include: additional security to protect actuation; issue multiple device commands with one request (make one request and fire it to all Modbus devices or all devices under the control of one service); provide the means to limit requests down to a device so as not to overwhelm it or wake it up).  These needs could also be incorporated into a combined metadata service but there are advantages to separation of concerns.
  • Low - Time series database support and applicability
    • Ian Johnson has an example of app service to InfuxDB export (snap in the store)
  • Low - where should tool/script for creating new device and application services be placed?
    • After the architect's meeting of Jan 26, 2021, it was decided that "templates" should be created in all SDKs to allow for the easy creation of new services (removing the old samples in the SDKs).  The templates will be a means for users to copy and create a new service with some instruction on how to rename and replace TODOs with necessary code.
    • After the templates are in place, there is a decision to be made about where automation can be placed to use the templates to create new services (versus a manual copy).  In the CLI, in a new tool, in a set of simple scripts?

On Hold Topics or Pending Research

  • High - V2 API - should we add security foundation added to that (per some of earlier V2 API designs via Dell and Bryon N)?
    • Adding token to authenticate a micro service call (is this in scope for Ireland)
    • May not be needed unless all services are distributed
    • We need to explore alternatives to provide secure / locked out service to service communications
    • ADR being created and to be reviewed in the Security WG.
  • Low - Digital twin (and LWM2M) applicability - being worked via liaison with DTC

  • No labels