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)
Zoom Link: 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
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 )
- We need to revisit CBOR binary support vs simple JSON / binary encoding (per Core WG meeting of 1/7/21).
- What are the criteria of acceptance of a module/library (license, usage, versioned, security concerns, etc.)
- Is it ok to accept a module/library that meets the criteria but could be smaller if we just did it ourselves (i.e. - is accepting a library that has 5 layers deep of imports ok?). How would we define / stipulate this as a criteria?
- James Gregg and Tony Espy to create short list of evaluation criteria based on James's list in High - How to handle binary data in V2
- Is CBOR still the right way?
- Simplicity versus performance
- We should have new requirements/use cases to change this
- Jim to find the objectors to CBOR before we cover and get any suggestions/requirements for non-CBOR
- Use of CLI to generate new application or device service
- Per Core WG and TSC meetings (1/20/21), there is a big desire to add a feature to EdgeX tooling to more easily generate a new device or application service (using a command line tool and some template found in the SDK)
- Question is whether this should live in edgex-cli or is this a separate tool?
- CLI for replacing curl scripts; this doesn't see to fall in line with objectives of the current CLI.
- Client keys in configuration; use the service keys as the constants for the map keys (per Core WG meeting of 1/21/21)How should we deal with example code? Example code for app services lives in holding. Example code for Device Services lives in the device service SDK (although to some extent, device random and virtual are examples). Security is about to create some example code for SSH tunneling. Should all this be collected somewhere? Should it live in Github or in the docs (or on the Wiki or other location)? Should it be consolidated? Is it managed code or is it "buyer beware" code?
- Jim White to use the evaluation list to review the 30+ library/module imports of edgex-go that are dynamically versioned (have no version number tag - example is bitbucket.org/bertimus9/systemstat v0.0.0-
- With the revised criteria list and module/library report, re-evaluate this at the next meeting.
- Does EdgeX work with IPv6? If not, what work needs to be accomplished and what are the impacts to the code base?
- Add a service dot setting to set up the adapter for listen on web services (Lenny to provide more details)
- EdgeX UI - it is for dev/test right now. Would we ever want to have a UI for production? Under what constraints?
- How should we apply semantic versioning to modules? When do we update the minor and major versions of modules? (comes from the Hanoi planning meetings)
- PR Template for conventional commits is now in place for all repositories for all PRs but without TSC approval. It doesn’t appear to be affecting any problem. We need to finalize the shape of this and officially approve the template by the TSC.
- Extract of Device Service requirements to ADR legacy - what are all the pieces that need to be moved there?
- Per the Hanoi planning conference - we need to better define "bound checking" so that a design (and eventual implementation) can be brought forth to meet the requirements
- Currently considering limiting the number of operations that can be performed on a service (like a device service) over a period of time or setting the max request size (that lends to DoS attacks)
- Can the solution be more globally applied?
- Design metadata about the “gateway” or host platform (identity, location, …)
- How do address module and component version release needs for examples (per Slack exchange with Luis Obando). go.mod in the examples helps - or at least some documentation on dependencies.
- We are up to 58 repositories in Holding. May need to look at some cleanup in the new year.
- Done - resolved via email
- Core/High - Ensure that service location data is pulled from trusted source (i.e. not Consul) (Tony's ADR)
- Covered in Security WG
- 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
- Med - Address how to get device resource info (for app services and Kuiper)
- Probably not ADR worthy
- Either provide Lenny’s convenience APIs or tool to dig out the device resource information in the (cached) profiles
- How/when to invalidate the cache if we use the profile-digging approach
- Med - Keep commit history from beginning to end (don’t squash them until PR approved)
- Med - Standardizing units of measure
- Med - Declarative Kong applicability
- Allowing us to drop Progress DB
- But can you configure groups/users ACL
- Only supports JWT users
- 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 (must be done before V2 is done) - Naming scheme changes for config.Clients (key name change)
- Use consistent name that all other services use for core data
- Consistency in the naming vs changing all the names to use service name as part of key
- Related to system management hard coded list of services.
- Separate issue in arch meeting – high once report back
- Other naming issues (secret store vs secret service)
- Opportunity to make all config/naming consistent
- Jim take resp – get WG leads – try to prioritize this survey
- 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
- Low - Digital twin (and LWM2M) applicability
- Low - Time series database support and applicability
- Ian Johnson has an example of app service to InfuxDB export (snap in the store)
- Allowing dynamic changes to device profiles
On Hold Topics or Pending Research
None at this time