Date: 19 - 20 July 2017
Meeting Slide Decks:
Day 1: EdgeX-TechCommittee-LondonMeeting-Day1.pptx
Day 2: EdgeX-TechCommittee-LondonMeeting-Day2.pptx
Meeting Recordings:
Day 1: https://zoom.us/recording/play/6sXvPwGnLfw-pJBGzKTgrQd8hAKiMVJhB9H0heGZmxmb_EW24ybBsztLI4dE2YYx
Day 2: https://zoom.us/recording/play/KfPPyJ5VWQjvn0LA7vBcAhLSy0qXHCit0A6JqX3RXVtMKiWO-C3mbSAzHifRDp0b
Agenda Topics
Barcelona MVP Objectives and Plan
Objectives
- Barcelona event is the target for this first product introduction. We are avoiding naming this a beta, alpha or v1 type release to imply still a work in progress at that point
- Identify which use-cases the MVP is intended to satisfy
- Discussion and agreement on OS and platforms for first release – suggest at least having Docker containers for Windows (Intel), Linux (Intel), and Linux (Arm)
- Review existing performance and footprint targets for Barcelona – agree these are still valid
- Discuss who/how performance is monitored
- Discuss what-if scenarios and alternative strategy if performance numbers cannot be met with existing Java/REST implementations
Plan
- Review and discuss current project plan
- Discuss resource needs, contributions, schedule and assumptions on which the plan is based
Core and Supporting Services
- Discuss and agree on MVP, MVP being…
- Harden the core services (core, metadata, command, config/registry)
- Harden the supporting services (logging, notifications, scheduler)
- Issues to address
- Logging and file based persistent causes OOM exception
- Consul was created for master/slave environments. Replace
- Device manager need
- Review and confirm resource needs and contributions to deliver the Barcelona release
Applications
- Discuss and agree on MVP, MVP being
- Harden the export services (export client, export distro, rules engine)
- Issues to address
- Spring Integration may be too slow to support large data volumes or multiple clients – alternatives, redesign, etc.?
- Discuss required MVP export needs
- Required pipe beyond MQTT, REST, ZMQ
- Which cloud (Azure, AWS, Watson, etc.) provider connectivity/integration must be demonstrated? [Note a minimal Azure IoT integration was completed by Dell).
- What formats above JSON and XML are required
- What transformations, compressions, encryption are required?
- Discuss need for export client UI to easily demonstrate dynamic export capability
- Discuss replacing Drools and rules engine. Timing and how best to support other analytics capability beyond Barcelona.
- Review and confirm resource needs and contributions to deliver the Barcelona release
Device Services
- Discuss and agree on MVP, MVP being…
- Small set of existing device services (see below)
- Harden the SDK and existing device services
- Simplify and clean up the SDK
- Discussion and agreement on what devices to support for Barcelona – suggest using Dell device services as start (Modbus, BACnet, BLE, SNMP, MQTT, Fischertechnik, Virtual) to start. Contributors will be solicited and encouraged to provide others or OS replacements or device specific additions.
- Discuss need for extending SDK to other programming languages. If not for this MVP, thoughts about how soon its needed and what languages we need to support
- Review and confirm resource needs and contributions to deliver the Barcelona release
Security
- Discuss and agree on MVP, MVP being…
- Outline general security architecture and services
- Potential use of existing security standards e.g. OCF Security Standard
- Design API “hooks” into existing services
- Create or identify baseline security services
- Review and confirm resource needs and contributions to deliver the Barcelona release
System Management
- Discuss and agree on MVP, MVP being…
- Outline general system management architecture and services
- Potential use and impact of LWM2M
- Design API “hooks” into existing services
- Discuss choice between providing some minimal system management services/implementation or using existing system management capability to exercise “hooks” and demonstrate EdgeX sys management
- Review and confirm resource needs, contributions to deliver the Barcelona release
Development Process, Builds and QA
Development Process
- How do we adhere more to an agile process at least within the working groups ?
- Discuss which development process we should adopt (i.e. Scrum or XP or DSDM etc.)
- Discuss how we go about implementing and managing the process
- What tools do we need to support the process ?
Builds
- Review existing build process – from code to Docker containers
- Review and discuss current code check process and any changes we want to make
- Branching, etc.
- Ownership of merge and approvals, etc.
- Versioning – discuss proposal to adopt Sematic Versioning http://semver.org/
- Discuss how best to support multiple hardware architectures (Intel/Arm) through build
QA
- Discuss how best to improve and insure quality
- Discuss responsibilities around QA
- Unit tests, integration tests (who creates, owns, inspects, etc.)
- System testing
- Blackbox testing
- Discuss test lab – who, what, where
- Review and confirm resource needs, contributions to deliver the Barcelona release
Demo for Barcelona
- Discuss ownership of organizing and building the demo(s)
- Discuss features that should be highlighted
- Discuss ownership of organizing and implementing marketing material
- Discuss general timeline – when does demo have to ship and how does this effect EdgeX planning
- User Interface needs – as it exists, EdgeX has no UI. How / who addresses this for the demo?
- Review and confirm resource needs, contributions to deliver the Barcelona demo and maketing material
Miscellaneous Topics
- Suggestion to start strategic and tactical Want List on the Wiki
- Strategic elements get reviewed by TSC and dropped on Roadmap where applicable
- Tactical items are reviewed by working group chairs for potential assignment or opened to the community to adopt and implement
- Longer term Roadmap
- Discuss EdgeX beyond Barcelona
- TSC ownership of the Roadmap area of Wiki
- Discuss possibility of combining some working groups
Above, the term “Hardened” means that the component in question …
- works properly for the intended use case (it may not be 100% complete implementations for all use cases or parts of a protocol for example, but it provides enough implementation to sustain the demo use cases for Barcelona and could support extension to the full needs or protocol in the future)
- handles errors and exceptions gracefully
- contains proper unit and integration tests
- follows good coding standards, and is well documented
- performs within the target measures established for Barcelona