Table of Contents
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.
Monthly: https://zoom.us/meeting/vpEufuytpzstxwJXp3nHvYoHt7mRqmscaw/ics?icsToken=98tyKuqtrTIvH92Vt1_Hd7MvA5X5buHylmlZgJtNzxHNFRlcShehO9BTP6F8Ec-B
Join Zoom Meeting
Zoom Link: https://zoom.us/j/353955907?pwd=MEhSQmlxQ1lLcCtsQ1lrSFh6cE0yQT09
Meeting ID: 353 955 907
Passcode: 150365
One tap mobile
+16699006833,,353955907# US (San Jose)
+1646558865612532158782,,353955907# US (New YorkTacoma)
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
Canada 855 703 8985 Canada Toll-free
Meeting ID: 353 955 907
Find your local number: https://zoom.us/u/abscayLpz ( https://www.google.com/url?q=https://zoom.us/u/abscayLpz&sa=D&ust=1570487240002000&usg=AOvVaw3baS0YLvMOVQhRUsVMH2C0 )ajhw77vTU
Meeting Agenda/Minutes
Mar 15, 2021: Meeting Minutes; Meeting Recording
Feb 16, 2020: special edition of the monthly architect's meeting to test holding Hanoi planning via conference call. Meeting will be from 10am to 1pm EDT
Agenda
...
- Review of current decisions (see https://wiki.edgexfoundry.org/display/FA/Monthly+Architects%27+Meeting?preview=/37912817/43581510/API%20V2%20Follow-up%20Meeting%20Notes.pdf)
- Device Service / App Functions committing to their own OpenAPI docs using the principles from the V2 ADR
- Depth of "common implementation" across sub domain applications. Does this end at the bootstrapping or are there additional layers to align? How do we know when it's enough?
- For Core/Support services, do we split V1 and V2 persistence?
- Start to think about which use cases we think would benefit from the addition of pub/sub
- Do we consider Support services optional? Should we approach Core-Data as Support-Data for V2?
...
- Blacklisting of devices and how/when to remove. Tony to argue on how blacklist APIs and delete APIs can be called by some system ; Trevor to argue how this needs to be automated. Implementation of any automation (whether all in metadata, via message bus to rules engine/app services, etc.) - all dependent on the first decision about whether to automate.
- Finalization of config-seed removal ADR (#0005)
- Revisiting holding and when work needs to enter holding (and what it takes to get out)
- Acceptance of DS and testing needs - how to bring a new device service from holding to the EdgeX repos (presented by DS WG – Iain, Tony)
- Bound checking issue (presented by Tony)
- Apache 2 licensing requirements (per Tony E message and Brett P (LF) and Ducan (IOTech) responses.Whether it was necessary and wise to move code from EdgeX org to holding only to go back to EdgeX org again (vs just make a new repo directly in EdgeX) - initially covered in Jan 15, 2020 TSC
- Address policy on patch/minor release based on discovery of CVE or other security issue (high/critical) - would we force dot release of all services, just affected ones, ??? For Consul and Mongo, we just minor rev'ed those services and containers. What if issue was in one of the go services? Would we have to minor release all (example go from 1.2.0 to 1.2.1) on all services even if only one was affected?
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)
...
Nov 18: Meeting Minutes; Meeting Recording
Open Topics
- Med - Standardizing units of measure
- Per meeting of 3/15, Jim to research more like the ANSI X-12 standard and see what other IoT/edge projects are using.
- Med - Declarative Kong applicability
- Allowing us to drop Progress DB
- But can you configure groups/users ACL
- Only supports JWT users
- Med - what's the future state of system management service(s) look like
- How to deal with dynamically adding/removing services
- Does it reside in registry/configuration service
- How to handle security issues
- Low - Is the Wiki the best place to document project decisions (those outside of or smaller than ADRs). This was our initial take. Should we revisit?
- 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 - Digital twin (and LWM2M) applicability - being worked via liaison with DTC
- 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.
- Revisiting holding and when work needs to enter holding (and what it takes to get out)
- Acceptance of DS and testing needs - how to bring a new device service from holding to the EdgeX repos (presented by DS WG – Iain, Tony)
- Bound checking issue (presented by Tony)
- Apache 2 licensing requirements (per Tony E message and Brett P (LF) and Ducan (IOTech) responses.Whether it was necessary and wise to move code from EdgeX org to holding only to go back to EdgeX org again (vs just make a new repo directly in EdgeX) - initially covered in Jan 15, 2020 TSC
- Address policy on patch/minor release based on discoveryof CVE or other security issue (high/critical) - would we force dot release of all services, just affected ones, ??? For Consul and Mongo, we just minor rev'ed those services and containers. What if issue was in one of the go services? Would we have to minor release all (example go from 1.2.0 to 1.2.1) on all services even if only one was affected?