Versions Compared

Old Version 3

changes.mady.by.user Jim White

Saved on

compared with

New Version Current

changes.mady.by.user Jim White

Saved on

Key

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

Code Freeze:  Apr 22, 2020

Release:  May 13, Delivery:  ~ April 2020


The Geneva release is likely to focus on 3rd party service certification, platform and setup guidance relative to EdgeX performance measures, and high availability concerns.

Release Themes and Objectives

will be a minor release (1.2) with a focus on testing, a few but important key features such as automated device provisioning and a replacement for the final Java service - the rules engine.

Table of Contents

Geneva Release Overview

Image Added

Release Themes and Objectives

  • Improved Security
  • Interoperability testing
  • Dynamic device provisioning/on-boarding
  • Alternate messaging support (to 0MQ)
  • Archive of Export Services - in favor of Application Services which was implemented with the Edinburgh and Fuji releases
  • DevOps Jenkins Pipelines
  • Provide an alternate local analytics service (archiving the Java-based rules engine service)
  • Deprecating the following:
    • Logging service
    • MongoDB support

General

  • Move to Go 1.13
  • Redis as default DB
    • Implement with username/password protection.
  • 0MQ Alternate between core and app services
    • Should help with Windows dev (long standing backlog)
  • Separate the configuration and registry APIs
  • Establish a document template for API information
    • Used to better define the Swagger documents
  • Use of Dependency Injection in Go services found in edgex-go

Core/Supporting Services

  • Combine/reduce UIs
  • Blacklist/whitelist of devices (w/ DS WG)
    • As part of auto provisioning
  • Alternate message bus provider (w/ App WG)
    • Allowing data from Core Data to be pushed to multiple channels / topics and how to deal with marking an event/reading as pushed in that circumstances

Application Services and App Functions SDK

  • Export Service archive/deprecation
  • Application services should provide for batch and send modes
  • Rules Engine Replacement (w/ Core WG)
    • JSON Logic and/or EMQX Kuiper implementation
  • Create a design and implement a means for application services to feed data back into core data
  • Support Cloud Event import (device service) and export (if not supporting Cloud Events model throughout) – stretch goal

Device Services and Device Service SDKs

  • Automatic/dynamic device provisioning capability
  • Array of data types (w/ Core WG)
  • Data filter design between DS and Core Data
    • Provide a design about how to implement this before implementing.
    • If possible, can the filter functions be shared across App Services and D.S. (w/ App WG)

System Management

  • Open Horizon “Walk phase” (TBD)

Security

  • Create a hardware secret storage design
    • HW secure storage abstraction layer
    • How to protect the Vault Master Key
  • Create and use a per service Vault token in the security services
  • Service token revocation and rotation
  • Blackbox tests of APIs through the API gateway
  • Design work
    • How to implement HTTPS in EdgeX (that is, how to protect all service endpoints with HTTPS)
    • How to implement role-based security across our all EdgeX services.

Test/QA

  • Device Service testing – complete testing for current set of EdgeX Device Service (w/ DS WG)
  • New blackbox tests to support V2 API changes on new Robot-based Test Automation Framework
  • Documentation – move all API definitions to Swagger (w/ all WG assistance)
  • Documentation – move from RST to Markdown
    • Explore documentation versioning – stretch goal
  • System integration / interoperability tests - Device Service read data -> Core Data -> Rules Engine or Application/Export Service -> Command
  • Implement enough performance testing in order to be able to answer key performance measures – extend existing Robot perf test summary suite developed during Fuji
  • Add unit tests/testing for global libraries. (w/ DevOps help) – stretch goal

DevOps

  • Move to Jenkins Pipeline
  • Apply Synk scan to other services and images (w/ all WG input)
    • Synk can’t do ARM images

Certification

  • Planning and design work toward certification and self-assessment for when LTS hits.

Vertical Solutions WG

  • China Project Team in place

Additional Release Notes

  • Geneva will not be LTS.  While no specific future release is pinpointed for LTS, the general hope is that the Ireland release will be a bug fix only, minor release that might be our best opportunity for an LTS.
  • Export services are removed from the Geneva release.  This required the approval of a backward compatibility exception for Geneva since it is no longer a major release.
  • Implement an EdgeX run service certification program on top of the self-assessment program implemented for Fuji.  This will allow third parties creating EdgeX services to verify their services as alternative or enhancing capability to those provided by the EdgeX open source effort. This will allow 3rd parties to add value (proprietary or open source) to EdgeX that customers can rely on to meet the EdgeX APIs and work without additional code change (enable a plug-and-play ecosystem). Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX). Additional certification processes may be developed around particular cross cutting features such as security.
  • Providing EdgeX users guidance on platform needs, sensor data throughput and deployment based on performance metrics.  Specifically, with the Geneva performance testing apparatus, the EdgeX community will be able to answer these questions for the user:
    • 1) Will EdgeX fit on my system? - size of EdgeX services, infrastructure, etc. and hardware/platform requirements
    • 2) What is the speed of data through the system? - from device service sensor data ingestion to the rules engine and back down through command to another device service to trigger a put command, how long does this take?
    • 3) How many “things” can be processed at a time? – with caveats on the type of thing, type of data, etc.
    • These questions need to be answered on real hardware (both Intel and ARM)
  • Improve EdgeX distributability and resiliency in face of issues or non-availability of some resources/services/etc. (typically for core and above services and not device services)
    • Insure all micro services follow 12 factor app methodology (see https://12factor.net/)
    • Allow services to be load balanced
    • Allow services to fail over
    • Allow for dynamic workload allocation
    • Allow services to live anywhere and be moved without lots of configuration to be changed in other services
    • Allow services to be distributed across hosts - and across API gateways (requiring service to service communication protection)
    • Support cross EdgeX instance command actuation (ex:  device X on EdgeX box A triggers action on device Y on EdgeX box B)
  • Provide an alternate local analytics service (archiving the Java-based rules engine service)
  • Address more vertical solution needs