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)
Zoom Link: https://zoom.us/j/353955907
Meeting ID: 353 955 907
One tap mobile +16699006833,,353955907#
US (San Jose) +16465588656,,353955907#
US (New York) Dial by your location +1 669 900 6833
US (San Jose) +1 646 558 8656
US (New York) 877 369 0926
US Toll-free 855 880 1246
US Toll-free +1 647 558 0588
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 )
Meeting Agenda/Minutes
Mar 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
- V2 API redo – continuation of ongoing conversation led by Trevor Conn
- 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?
- Additional open architect topics (time permitting)
- 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?
- Last 20-30 minutes of the session, reflect on good/bad/ugly of the meeting. Does this format fit for Hanoi planning? If so, how/when should we hold Hanoi sessions.
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
- 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?