...
Nov 18: Meeting Minutes; Meeting Recording
Open Topics
- High - Service List ADR review (with need for some implementation / design details)
- High - Metrics ADR review
- High - Unit of Measure ADR review
- 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.
- High - new ADR requests per planning meeting
- allow for dynamic updates to device profiles (device services)
- validation of device protocol properties (device services)
- micro service authentication (security)
- High - research and decision on Declarative Kong (Jakarta planning meeting)
- Drop in replacement? Impact? Does it help significantly with size?
- Allowing us to drop Progress DB
- But can you configure groups/users ACL
- Only supports JWT users
- Med - Is the Wiki the best place to document project(low level architecture or design) decisions (those outside of or smaller than ADRs). This was our initial take. Should we revisit? (Per Jakarta planning meeting)
- Jim to research other projects and how they handle this
- https://github.com/kubernetes/community/blob/master/sig-architecture/README.md
- Med - Replacing poor 3rd party libs - per Jakarta planning meeting (6/21)
- Relook policies for 3rd party libs and how to evaluate, especially for device services. Also, should we start to fork these “immature” libraries
- Low
- Med - address how to provide services, UIs, startup scripts/services, etc. with a list of system services.
- SMA needs the list of services
- UI needs the list of services
- Secret bootstrapping needs to provide tokens to services
- Considerations
- What if Consul is not in use (or should we even allow this)?
- What if app or device services are added at runtime (post bootstrapping)?
- There are some chicken/egg scenarios; security may need the list in order to provide each service with the proper token before they come up and register with the registry service
- Med - per Core WG meeting of 4/22/21 and Jakarta Planning Meeting (6/21) - how much info should be put in errors and log messages.
- There is a concern about putting to much information in from those familiar with commercial products
- Temporary decision was to provide enough so that someone could debug the problem with the information provided and not to be concerned with exposing intellectual property since everything is open source.
- 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?
- planning meeting: need a survey to address but don't believe we have an issue
- Potentially is an issue in defining what is Error/Info/Warning
- Low - 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 DTCLow - 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?
...
- 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.
- Low - Digital twin (and LWM2M) applicability - being worked via liaison with DTC