Jan 2018, TSC Face-to-Face

Action Items and Resolutions

edgexfoundry.org | @edgexfoundry

Day 1

edgexfoundry.org | @edgexfoundry

California Preview Release

• We should be careful to call this a preview and not a release
• Messaging and terminology is important to setting expectations
• Targeting Jan 31^st as our preview availability
• Go Lang Export Services (Mainflux/Cavium) will have Consul integration
• We will have Docker compose files for Java and hybrid Java/Go for 0.5.0 artifacts
• From DevOps, have the cross compiling and artifact production by availability date
• Use tags for artifacts but not formal “release”
• There will be formal announcements from LF on the preview availability
• Blog posts will be created on the performance numbers

​

edgexfoundry.org | @edgexfoundry

Go v. Java (or other language) support

• There will be one reference implementation of the micro services offered by the EdgeX community
• Meaning the community will (barring any other considerations) support one reference implementation at a time – which can be in any language
• Community work on a service, or contribution of a new reference implementation will be weighed against the current reference implementation
• Any implementation must meet the API and quality agreements for that service
• Today the services are almost all Java. For California, the ref impl of core services and perhaps some of the export services will be in Go Lang
• The preview availability will start to highlight this move
• Organizations/individuals can choose to maintain and contribute other language implementations of services
• These will be tested against the API/quality requirements
• They will either be deemed sufficiently “better” by the TSC and become our reference implementation or they will be listed as alternate implementations for use by the community
• Example: someone may continue to maintain the Java core services to make them API and functionality equivalent of the Go Core services. Because of the performance differences, these would not be “better” but could be otherwise equal and continue as alternate implementations
• The TSC does not require the contributors maintain alternate implementations. If an alternate is not maintained close enough to the reference, it is moved to “archive” status by the TSC
• Security/Sys Mgmt work will have to be done to reference implementations – meaning 2 language implementations at this time
• Core services (export services when deemed the ref impl) will need Go additions
• Other services (logging, notification, etc.) would require Java additions at this time

edgexfoundry.org | @edgexfoundry

California Release – what’s in

• Blackbox testing is highest QA/Dev Ops concern
• Performance testing under that
• Arm native testing was high priority by TSC members, but not as high to community at large
• Final matter for voting TSC/board to decide
• Developing Device Service SDK in other language(s) – Go or C
• SDK’s are more important than developing more DS for other protocols
• A part of the Wiki (or EdgeX documentation set) should provide attestation as to who has tested EdgeX on which OS
• This attestation specifies that Blackbox (and any other tests) have been run and what issues were encountered
• Independent attestation does not imply any official community endorsement (or repudiation)
• As a general statement, the community says EdgeX is and will continue to remain platform agnostic with regard to hardware and OS.
• We always, and forever more, seek and accept for consideration other contributions and will incorporate those into the release as possible

​

edgexfoundry.org | @edgexfoundry

California – what’s out �don’t panic – this is just for California – these items will be moved to roadmap for Delhi??

• Additional export connectors
• Groups like NOV plan to offer InfluxDB and OSI Soft/Pi connectors
• Expose command information north bound (export of actuation information and APIs)
• Additional Device Services
• Welcome DS from other vendors and 3^rd party, but not the priority for this release
• Official OS support
• Welcome companies to test and formalize their results, but no EdgeX official list of supported OS
• No official UI support
• 3^rd party provided

edgexfoundry.org | @edgexfoundry

Security California Release

• A OS reverse proxy will be selected and integrated to EdgeX
• Integrate with AAA service (see below)
• The implementation will offer both OAUTH and Basic Auth options
• Use of the network layer to protect access
• I.e. no changes to existing micro services at this time
• Currently looking at Traefik for dev/test and possibly NginX for prod
• This will be for HTTP/S only (meaning security for MQTT and other protocols will not yet be provided)
• An open source Authentication and Authorization server (s). (E.G., Keycloak, Dex, Hydra, …) will be selected and integrated to EdgeX
• Prod deployment models will require integration with centralized AAA.  Initial solution will be to integrate with reverse proxy
• Data Protection Services via HashiCorps’s Vault will be integrated with EdgeX
• This will provide Key Management, Certificate Services, Encryption
• API abstraction to allow 3rd party implementation/extensions
• Some additional research/work needs to be finalized for California around license, external CA support, local crypto library, bootstrap provisioning, local secure store for bootstrap credentials, unattended startup
• For the California release, the goal is to accomplish implementation without rework of the micro service APIs, with the possible exception of export services

​

​

​

​

edgexfoundry.org | @edgexfoundry

Security Roadmap (beyond California)

• The existing Security Roadmap still generally stands and serves to outline future work
• More requirements need to captured from customers to sharpen the roadmap going forward (task for the Security WG)
• For example, the current roadmap is focused on securing the EdgeX “gateway” and remains the priority
• In the future (perhaps by Delhi) a roadmap around securing EdgeX’s devices will be outlined
• This may include research and considerations around specific technology like enrollment over secure transport (EST)
• Additionally, input from IIC, OpenFog and other IoT related consortia will be mined for both security requirements and EdgeX security roadmap items

edgexfoundry.org | @edgexfoundry

Performance Targets (for California)

• More requirements need to be collected from end customers for specific use cases and target platforms
• For purposes of a baseline and to establish targets for the Test/QA working groups to build performance tests against, we establish a “developer community” target platform
• The target is to run all of EdgeX (all the services to include the virtual device service) on a Raspberry Pi 3 (1 GB RAM, 64bit CPU, at least 32GB storage space, running Raspbian Linux distro)
• This is not an endorsement of the platform as our favorite or otherwise endorse platform
• It only suggests the general characteristics of a “developer community” target platform
• This may not be entirely feasible without all Go replacements, but is the target and the development community will report back when/where this is not possible
• For example, it is unlikely the target security implementation will fit on this size platform
• Additional “developer community” targets
• Startup in 1 minute or less (post OS boot – from micro service start to all services up and available)
• Throughput for one piece of data (with one IP device connected by hardwire – versus wifi) from data ingestion at the Device Service layer, through Core Data, to Rules Engine and back down through Command Service finally to Device Service for actuation will be < 1 second

edgexfoundry.org | @edgexfoundry

Generals

• More requirements from the “user” or customer community are needed across the board as more POC and real implementations using EdgeX take shape
• We need a “feedback loop” that invites the EdgeX community to share their deployment activity, lessons learned and requirements
• This topic is pushed to the TSC and board for consideration on how to implement
• The LF has many projects that institute something like this for possible consideration

edgexfoundry.org | @edgexfoundry

Day 2

edgexfoundry.org | @edgexfoundry

System Management

• Affirmed 2 system management elements for California release:
• System management API (action, alerts, metric) as discussed and outlined here
• System management Agent
• More design work needs to occur around this work
• For the purposes of discussion going forward, this is called Application (as in EdgeX micro service application) Management
• The broader, post-California system management functionality requires more discussion (see F2F deck as well as here).
• This may require the addition of another project
• For the purposes of discussion going forward, this is called Application and System Management
• System management includes platform and device management

edgexfoundry.org | @edgexfoundry

California Resource Discussion

Security: lead David F & Riaz Z with help from ForgeRock, Dell Technologies/RSA and Beechwood (Rodney) engineers

Core/App WGs: except for changes based on Security/System Management, no large work

Device Service Go and C SDK: Canonical (Tony) with Cavium on Go SDK, IoTech on C SDK

With some sore of demo device service created (but not full 6 DSs done by these SDK)

DevOps Native Arm testing: Jeremy with Cavium assistance. Cavium also to provide Arm test environment

Test/QA: Andy Foster (IoTech) expand black box tests to all services and set up performance tests

System management: no lead, no resources identified at this time

Delivery manager:

​

edgexfoundry.org | @edgexfoundry

Documentation for California

• IoTech (Andy F) to have:
• Docs in GitHub
• Autobuild to generate docs through CI process
• Relook of RAML choice, auto generation of API docs, to be covered in Core WG

edgexfoundry.org | @edgexfoundry

Roadmap Discussion

• For each road map item, we need a small paragraph that describes each (Jim White action item)
• Clean up of current road maps (to be done by Jim W)
• Message infrastructure (based on outcomes of architecture discussions)
• DS SDKs moved up to California
• Role orchestration under system management
• Fold some of the topics under “fog” as appropriate
• Multitenancy - add report of data flowing, fine grain instrumentation

​

edgexfoundry.org | @edgexfoundry

Roadmap Discussion

• New or updated items
• Technical Debt/Refactor (what and when) - need to put some dates next to architectural discussions tomorrow
• Device service rewrites (ex: BLE, Bacnet)
• Disruptive testing (start by Delhi)
• Cert Process - want to have outlined by Delhi
• Probably will include different levels of certification (micro service, versus “box”, etc.)
• Virtualization/fault tolerance/resiliency/decentralized peer-to-peer capability (post Delhi)
• Resiliency, in general, is something we need to work on more for all releases
• Distributed ledger/blockchain (post Delhi)

edgexfoundry.org | @edgexfoundry

Deemed Not in scope of EdgeX

• Security monitoring
• network management
• secure boot/trusted boot/HRT
• platform attestation (share measurements of trusted boot measures)
• security below the interface level (see red arrow)

​

edgexfoundry.org | @edgexfoundry

Code Contribution Process

• Per picture here
• Jim W. to write up and get feedback
• Get TSC approval

edgexfoundry.org | @edgexfoundry

Deployment/orchestration

• More to be discussed today
• Options/opinions to be considered
• We want to envibe the ecosystem; make it easier for customers
• We need a stake in the ground and Kubernetes appears to be leader
• We don’t want to make a technical bet and get it wrong
• Remember Kura and OSGI
• We want to provide “support” for Docker/Docker Compose; we offer community “recipes” for other options (Kubernetes, no containerization, etc.) somewhat like was done for PCF

edgexfoundry.org | @edgexfoundry

Day 3

edgexfoundry.org | @edgexfoundry

Release Plan and Schedule

• Keep to April/October releases per year
• June for California based on amount of work
• Use names proposed but replace Guangzhou with Geneva
• Events
• Keep Hannover Messe
• Add IoT Solutions World Congress
• Need one other event somewhere in the states - to be determined and pasted back to board, TSC chair and marketing to determine event
• Interop, Embedded Linux Conference, FOSDEN, IIC shows all brought up as possibilities
• Helpful if members can integrate EdgeX into their own booth displays

iic

edgexfoundry.org | @edgexfoundry

Face-to-Face Meetings

• Going forward, the face to face meetings should be held right after the releases
• Approximately April/May for spring F2F
• Approximately Oct/Nov for fall F2F
• We will avoid having F2F with large event where people have to do booth/demo coverage and also attend 3 day F2F
• Next Face to Face meeting should be in late June after the release
• Venue TBD - looking for a member company to offer facilities

edgexfoundry.org | @edgexfoundry

Other Events

• TSC favors Meetups
• Easier to facilitate and can reuse a lot of the presentation materials
• Boston coalition trying to set one up near term
• Jim W to start a page using Austin Meetup slides to provide place to share potential slide decks
• Hackathons require a lot of work
• Not discouraging but requires volunteers to establish and run them
• If we do hold any, it should be on how we make EdgeX “sexy”
• Focus on AR/VR, AI, etc. apps on top of EdgeX
• Contests that have a prize for some needed EdgeX piece or valuable add on may be another alternative way to encourage community involvement
• Review with TSC and Marketing going forward
• Full blown EdgeX training may be 3rd (behind Meetups and Contests) way to get involvement in the future but requires a lot of work
• Some companies already working on this

edgexfoundry.org | @edgexfoundry

Day 3 - WG Architecture Issues

edgexfoundry.org | @edgexfoundry

Deployment/orchestration - revisit

• Resolved for now…
• Agree to continue to support Docker and Docker Compose as current deployment mechanism for EdgeX
• Allow others to present alternatives and the +/- of those solutions
• Boran @ Thales is planning to provide Kubernetes solution
• Mainflux is looking at non-container solutions
• Allow others to present these and other options and allow the community to weigh in on what is officially supported long term
• Allow these solutions to be communicated via things like the blog to demonstrate a “recipe” for those with early interest

edgexfoundry.org | @edgexfoundry

Repository Naming

• All code contributed will first enter the temporary repository which will be a separate GitHub Organization (aka the “sithub”)
• Jeremy/Core WG to work out name for the new org (perhaps EXF or something like this)
• Once accepted per the newly defined process, it enters the main org GitHub repos (edgexfoundry) or gets rejected and removed
• Vertical Solution WG repos will have a vertical solutions prefix
• Jeremy and DevOps to set up names for Smart Factory and Oil/Gas WG repos prefix.

edgexfoundry.org | @edgexfoundry

Messaging/Message Infrastructure

• Agreed to continue to have REST as an always available communication protocol for all services
• Short term - no changes
• Keep 0MQ in place between Core and other services for California release
• Long term - have community members present alternatives with +/- study (taking the same approach as with deployment)
• Requirements (as we know them for now) for messaging
• Better latency than offered by REST
• Offer asynch comms
• Offer better QoS levels/options
• The community is not sure about broker versus broker-less; it depends on use case and other requirements

edgexfoundry.org | @edgexfoundry

Streaming Analytics

• No change to the current strategy/architecture
• Allow analytics engines to receive data directly from core data (so long as the EdgeX format is ok)
• Allow analytics engines to receive data from the export distro (when filtering, transformation, etc is needed but with more latency)
• More requirements and 3rd party analytics provider input needed
• A CEP or other lighter rules engine may need to some day be placed below the core layer
• For now, this can be built into the Device Service at the discretion of the DS creator

edgexfoundry.org | @edgexfoundry

Device Service SDK

• Need more requirements (or complete requirements started by Dell)
• Tony E (Canonical) to take the lead to drive the requirements document forward
• Drive out design from those requirements and try to insure the Go and C SDKs follow the same general designs and address the same needs
• Security will not yet be addressed in these requirements

edgexfoundry.org | @edgexfoundry

Service Naming/Startup/Cleanup/Availability

• Many issues with regard to micro service naming, startup, cleanup and availability need to be designed into a common service base
• Great discussion with regard to how to make the ID of a service immutable but also allow some dynamic behavior
• Jim W to take a shot at redesigning a base service to address all these issues

edgexfoundry.org | @edgexfoundry

Go Code Reorganization

• Everyone agrees to move to single mono repo for Go code
• Also agreed to not have a vendor folder in GitHub to avoid contamination of license agreements
• If vendor code used becomes not available, this is a larger issue
• Use Glide to control what versions of what vendor and EdgeX packages get brought in
• Fede (Cavium) and Drasko (Mainflux) spearheading the example of this mono repo
• Fede to demo at the next Go Meeting
• Issues to be address: Glide file and glide locks and how to make sure latest EdgeX code is always used by default

edgexfoundry.org | @edgexfoundry

Line Endings

• Move to use *nix line endings
• Requires all Windows developers to configure tools appropriately
• Mainflux/Cavium/Canonical teams to provide documentation on how to configure appropriate line endings and make a part of the developer contributor pages

​

edgexfoundry.org | @edgexfoundry