...
Nov 18: Meeting Minutes; Meeting Recording
Open Topics
- We need to revisit CBOR binary support vs simple JSON / binary encoding (per Core WG meeting of 1/7/21).
- 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
- High - How to handle binary data in V2
- 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)
- 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)
- 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?
Non-prioritized items
- Allowing dynamic changes to device profiles
...