Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Meeting Time and Conference information

Meeting Time:  3rd Monday of each month at 1pm EST as needed (if Wednesday at 8am PT on a bi-weekly basis, i.e. alternating with the TSC Meeting. If there are no agenda items, the meeting is will be cancelled)

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

Topic: EdgeX - Monthly Architects Meeting
Time: Nov 30 2020 10Time: Jan 18, 2023 08:00 AM Pacific Time (US and Canada)
Every month on the Third Mon, until Nov 18        Every 2 weeks on Wed, until Dec 4, 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

...

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: https://zoom.us/u/ajhw77vTU

Meeting Agenda/Minutes/Recordings

Currently running bi-weekly:

Previously run monthly:

Open Topics

...

  • Covered in Security WG

...

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

...

  • Review hybrid app-device service UCR (and any subsequent ADR) with the community
  • What to do about the future of system management

...

Could we remove device profile and device name fields in reading (and just use those in Event)?

...

Would anyone need to query Readings and need the profile or device name when they just pulled Readings independently?

Are there other places where Readings become divorced from Events and we need to consider the consequences of duplicating fields in each? If so, would it be better just to have Readings have a reference to its “owning” Event?

...

  • Allowing us to drop Progress DB
  • But can you configure groups/users ACL
  • Only supports JWT users

...

  • 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

...

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

...

  • Ian Johnson has an example of app service to InfuxDB export (snap in the store)

...

  • 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?

Non-prioritized items

  • Allowing dynamic changes to device profiles

On Hold Topics or Pending Research

  • None at this time