1. MVP Discussion

2. Agenda – Day 2
Note the agenda for day 2 was largely conducted as shown with the addition of another session on security in the morning.
Test/QA (9am)
DevOps/Build/CI (10am)
System Management (11am)
Productization (1pm)
Deployment, delivery, documentation – how to provide smoother setup for end users
California and beyond roadmap discussions (2pm)
High level goals and objectives of next few releases
Discussion of DevOp or other related issues with US LF DevOps team (3pm to accommodate US call ins)
Review MVP for LF
Discussion questions/open items/issues
Misc/Wrap (Keith/Jim led - 4pm)

3. QA & DevOps Committee Andy Foster

4. QA & DevOps Committee At Boston meeting two WGs proposed:
QA andTest WG
Develop Test Harness/Framework
Provide means to measure performance, footprint, etc.
DevOps WG
Improve EdgeX installation
TSC has decided in the short term that these groups should be combined into a QA and DevOps committee that reports to the Core WG

5. QA & DevOps Committee Andy Foster

6. DevOps/Build MVP MVP Stretch
Move to a more Agile development process
Automate build of code and docker microservices (check with LF DevOps)
LF DevOps question – how easy to provide Maven Repos or Maven style access to Nexus?
Automate unit (white box), functional (black box) – [single micro service API tests] and integration (black box) tests [micro service to micro service tests]
Automate CI pipeline
Define check in process (e.g.
Define branch model (e.g.
Define versioning scheme (see
Tech committee review and provide comments on these by July 31st (Andy to finalize list for review)
Identify maintainers and committers (see
Request dev community ( by Dell) to review policies/procedures – first week in Aug
Meeting in a couple week adopt / educate shortly there after
Stretch
Automate build of API documentation (Javadoc, raml-doc ?)
Research project for the future – let the community help guide, think about possible funding for better assistance/tools
Make part of development rules as far as standards/styles to support
WGs should adopt Agile development process (i.e. Scrum or XP or DSDM etc.)

7. Continuous Integration (CI)
Developers
Testers
Source Control Server
Integration Test Script
Functional Test Script
Source Code and Unit Test Script
CI Server
Build Server
Code Analysis
(Optional)
Compile
Unit Test
(White Box)
Private Docker Registry Server
Docker Build for Testing
Functional Testing Server
Execute Functional Test
(Black Box)
Initialize Test Env.
Integration Testing Server
Execute Integration Test
File Server
Copy Artifacts
Public Docker Registry Server
Docker Build for Production
Trigger
Return Reports
Download Files
Other Actions 1 2 3 4 6 5
Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control.
CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion.
Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the trunk or main).
Start LF DevOps discussion
IoTech fill out some details and provide want/need list for DevOps/LF

8. QA & Testing Barcelona MVP Testing Stretch California
Unit tests (white box)
Create black box test framework to support:
Functional tests – docker based micro service test framework that allows for the testing of individual service implementations via their external (EdgeX defined) APIs
Integration tests – as above, but involves running a complete suite of integration tests
all services should be running each time the tests execute
Performance tests (latency, throughout) and footprint
Platform tests (different OS on Intel) - Linux (Unbuntu Classic, Unbuntu Core 16, Debian 9, Alpine (latest)), Windows (10, 10 IoT 2016)
Stretch
Scalability, soak/stability, automated code reviews/coverage
California
Platform – testing on ARM
Test lab with more representative set of devices

9. QA & Testing Barcelona MVP QA
how to manage bug tracking/issues – reporting (e.g. and prioritizing (e.g. ues.md)
coding standards – adopt Google Code Standards (link to be provided) to be double checked by Dell teams
Build check style into CI build process – talk to LF DevOps
testing guidelines (e.g. ting.md) – IoTech to research and provide recommendation
Product release process and approval

10. Resources Barcelona MVP Resources Stretch
Appoint Build/Bug Czar to monitor builds and scoreboards + monitor incoming bugs and prioritize
Dell EMC is RocketChat / Support Czar
IoTech Bug/Build Czar
CI Server – Jenkins
Code repository – GitHub
Bug/Issue tracking – GitHub Issues (could JIRA be used instead?? LF question)
Black box testing framework (IOTech)
Integration tests (IOTech)
Potential research, funding for plugins , etc.
Performance and footprint tests (IOTech)
Supporting services unit and functional tests (Dell and WG leads for various areas)
Apply standards to tests (Kubernetes template/pattern) as determined/recommended by IoTech
Stretch
Test lab setup

11. Other TSC review and approval of the following templates:
Project Principles:
Project Incubation Exit Criteria:
Project Lifecycle:
Proposal Template for EdgeX Project:
Release Taxonomy:
Technical Work in the EdgeX Foundry Project:
Working Group Charter Template:
Andy/Team final review – provide to Jim / Brett – send tech community review (July 31)
Larger community review/comments
Educ session August

12. Additional Security Discussion
Boran & Riaz

13. Security Segway
Code signing – how do we insure integrity of code artifacts for Barcelona
Hashes of artifacts – Docker hash
Walk before we run
Users do manual verification if they so choose
Post Barcelona – topic for core working group with security WG representation (Jim to schedule separate meetings closer to Oct)
Cross sign Cas
Need Security WG proposals/requirements/business and developer impact

14. Salim AbiEzzi / Jim White
System Management MVP
Salim AbiEzzi / Jim White

15. Sys Mgmt MVP for Barcelona
Define the EdgeX system management story but postpone a lot of implementation to California
WG to agree on requirements
WG to agree on what features are going to be in EdgeX and what is reserved for OS, 3rd party systems, other open source systems, etc.
WG to define what system management services need to be implemented as part of EdgeX (if any)
WG to define what system management hooks need to be implemented
WG to define any system management standards that will be followed/used in system management implementations (ex: LWM2M)

16. Sys Mgmt Stretch Goals
Add some simple system manage hooks/capability into BaseService of EdgeX micro services
Dell has already done some POC work with things like start, stop, …

17. Productization
Keith Steele

18. “Productization”
How do we make deployment of EdgeX easier for end users?
What will end users need to more easily adopt EdgeX?
What will “delight” users?
Make them claim EdgeX is easy to use
Make them claim EdgeX is easy to develop for
Are there MVP in this area for Barcelona?

19. What is desired EdgeX must be easy to access
May be for multiple uses: developers, and end users as examples
Must have decent documentation
Must have good tutorials and examples
Release notes

20. Problems are faced by 2 different communities
By developers (our focus first since Barcelona release is not really being sold)
Device / silicon providers looking to build device services
System integrators
Micro service developers
IoT application providers (IBM, Foghorns, etc.)
Open source community individual contributors and hobbiest
Educational uses (future??)
End users of EdgeX (want to run EdgeX but may be non-coders)
Decision makers
May include some coders that want to explore EdgeX, but not yet get into the details of the code

21. What are the precise issues (highlighted priority issues)
How do I download, install and eval from a higher level before I develop (this could be a commonly shared need across Developers and End Users)
How do I get/use Docker before doing development
Git pull for all packages in order to focus on specific service
Getting all the code (Boran – chair, Tyler, Tony on point to provide mid August recommendations)
Getting the SDK (for device service developers)
Map(s) of start here, figure out where to start
Moving between state of code in git repos versus docker images and using both
Documentation is inconsistent (in flow and content) (Andy – Chair, Jim, and 3rd person TBD on point to provide mid August recommendations)
Template??
Manual sleeps between states (better orchestration)
Code examples to how to build various elements/micro services
Explanation of some of the basic concept (ex: device discovery, scheduling, service discovery)
Wiki not up to date or accurate (ex: device virtual service – some older than others) (combined with Andy’s task)
Instructions on how to connect connect
Make sure review process take care of documentation as well as code
Address format/delivery
Incorporate documentation output to build process
Wiki is produced from code repository??

22. California and Beyond Road Mapping
Keith Steele

23. California MVP Strawman
These items are not set in stone
To be determined by the technical committee(s)
Themes and MVP are WIP
Some ideas to foster discussion, directions and strategy

24. California – Themes
Deliver on system management & security implementations
Deliver on mission critical / reliable platform promise
Not RTOS level critical, but more near real time performance
Improve overall performance and deliver to target performance #’s
Replace core services with Go services
Additional connectivity
Some additional north side connectors
Some additional device services
An additional Device Service SDK in 2nd language
Demonstrate EdgeX in real world POC/Test Bed
Potentially via Test bed group like IIC
When and where are these tackled:
Use Cases????
Relationship to OMG, IIC, …

25. California – General MVP
Expand OS support
Mac?
Other flavors of Linux?
Support Arm
Provide EdgeX UI

26. California Core Services MVP
Meet all performance targets
Go services for core
Stretch – Go services for supporting services
More dynamic configuration
Address use of Consul as config/registry?
Implement security & system management API hooks

27. California Application Services MVP
Define and meet performance metrics
Number of clients
Number of messages exported/sec
Support additional cloud integration(s)
Ex: Watson, Greengrass, …
Support additional export feature(s)
Additional formats (Ex: Haystack, OPC-UA, …)
Additional endpoint types (Ex: DDS, AMQP, …)
Potential use of hyperledger
Implement security & system management API hooks
Additional export capability
Enrichment services
How best to facilitate client command requests/actuation

28. California DS/SDK MVP Alternate language DS SDK
SDK Tool plugins to facility developers
Ex: Eclipse plugin
SDK download (non-github oriented)
New and/or updated Device Services
Real BACnet or BLE
Additional DS (i.e. Zigbee, OPC-UA, CANBus, …)
Reduce/optimize Java DS (remove Spring Framework, etc.)
Updates to SDK get propagated back out to existing DS
Via common shared libraries
Implement security & system management API hooks

29. California Security & Sys Management MVP
The first implementation of
Ref Impl security micro services
Demonstrate EdgeX management via System Management app of choice
Ex: Pulse IoT Center, System Center, …
Secty and Sys Mngmt API hooks in other micro services
Security testing framework
Demonstrate EdgeX software updates
Updates to non-EdgeX components (drivers, end-devices)
Root of trust – what defines and how to implement
Code signing – how to certify integrity of the system

30. Post California Release Objectives
Real time device services/core
Message or alternate communication infrastructure (non-REST) between services
Micro service certification process
Validate a replacement micro service satisfies APIs
Validate a replacement micro service conforms to adopted deployment/delivery facilities …
Facilitate East/West capability
Failover, scalability
Device from EdgeX A triggers action on device on EdgeX B
Privacy Concerns
EU laws and affirmation about data use/storage/etc.

31. Timing and Venues Do we agree on 2 releases a year? YES
Individual micro services may release outside of 2 releases
With approval of TSC
What is the general timing of the next few releases?
What events are the targets for the next future releases?
To be discussed with TSC – better structure

32. Miscellaneous & Wrap up
Keith Steele

33. Barcelona MVP Agreement
Unanimously agreed upon MVP by the technical committed
As of July 20, 2017 London meeting
To be completed by Oct 1, 2017

34. General MVP Barcelona supported OS Barcelona supported hardware: Intel
Windows 10 (latest 2016 version – which is?)
Linux, Ubuntu classic (but does not enforce secure boot)
EdgeX supports and welcomes other OS providers to test and validate EdgeX works on their OS
Example, Canonical plans to test/validate EdgeX on Ubuntu Core 16
Barcelona supported hardware: Intel
EdgeX welcomes and will support 3rd party provided Arm support
Performance targets stand, but may not be achieved in this release
EdgeX to develop performance tests to show current performance metrics
No significant performance-specific work will be accomplished in this release (unless it is easy to achieve with no other impacts)
EdgeX will provide early Go performance numbers to show intended path to achieve performance targets
EdgeX will use current scalability metrics on devices, collection, etc. as scale guidance
More formal scalability concerns to be addressed in future releases

35. Barcelona Service Hardening MVP (owner WG leads)
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
Following some prescribed standard (like Oracle, Google or Twitter guides for Java)
Performs within the target measures established for Barcelona
Code base is not exploitable
API set is solid – WG issue for now; may need to be cross WG issue

36. Application MVP – Owner Janko
Harden as defined above
Azure IoT Hub integration (improve/clean up)
Provide routing to endpoints by device id
Support MQTTS and HTTPS for endpoint distribution
No additional formats/transformations/filters/etc.
Provide guidance on number of simultaneous clients that can be supported
Stretch: binary message format distribution (picking one to start)

37. Core & Supporting MVP - owner Jim
Harden as defined above
Fix known bugs (logging OOM, …)
Remove/clean up unfinished features (Device Manager)
Stretch
Core services in Go (at least enough to provide performance plan/story)

38. DS/DS SDK MVP – owner Tony
Harden as defined above
Provide Dell 7 DS as MVP (Jim owner to get DS in open source ASAP)
Clean up SDK (and DSs)
Improve documentation
Be more developer friendly (see improve tooling - stretch)
Merge device-sdk into SDK tools
Cleanup scheduler
Apply cleanup back to DS (with exception of BACnet and BLE)
Stretch
Improve tooling (Eclipse Plugin)
Real stretch - Remove redundant code from Device Services/SDK to shared libraries
Investigate Go base device service

39. Security MVP – owner John
No implementation as MVP
Build longer term roadmap – the EdgeX security story
Agreement on what security features are going to be in EdgeX and what’s going to be provided by the platform that EdgeX runs on (example: the underlying platform must have a keystore)
Agreement on security requirements
Define what EdgeX security service(s) need to be eventually implemented
Define what security hooks need to be added to the existing micro services
Define what standards, protocols, etc. are going to be adhered to and followed by EdgeX (ex: IIC specs, OAuth tokens, etc.)
Provide guidance on how security features can/should be tested

40. Test/QA MVP – owner Andy
Unit and integration tests for all micro services (all public methods)
Unit and Integration tests to be provided by developers for all micro services
Implement Blackbox testing
IoTech working to select and implement black box test framework
Will also allow performance tests to be run so that metrics on performance can be measured
Testing must occur on all supported MVP platforms
Have check styles in build process
IoTech to work with LF to build check styles into build process
Based on call with LF, already there but need to be turned on
Setup Bug tracking system
IoTech will take role of Bug Czar (at least until end of year)
Work with LF to implement bug tracker (leaning toward JIRA – depends on pricing)
Dell will continue to take role of answering Rocket Chat and list questions until the end of year. Will funnel real bugs that come in to Bug Czar

41. DevOps/Build MVP – owner Andy
Automate build of code and docker microservices (LF DevOps indicated should be done by end of July)
Implement standards on code commenting, branching, versions, …
Andy and IoTech researching existing LF work and options on code comment styles/ check in / branching/ versioning processes.
Providing recommendations for adoption to tech committee by July 31st
Keith/Brett/Jim will tech committee to review and comment first week in August
Adoption shortly thereafter – along with meeting to provide education
EdgeX hereby adopts the Google code standards (aka Style Guides) for all code.
Stretch
Automate build of API documentation (Javadoc, raml-doc ?) IoTech and others researching
WG allowed to setup their processes (Agile, Scrum, etc.) as they see fit (no community wide process for now)

42. Continuous Integration (CI)
Developers
Testers
Source Control Server
Integration Test Script
Functional Test Script
Source Code and Unit Test Script
CI Server
Build Server
Code Analysis
(Optional)
Compile
Unit Test
(White Box)
Private Docker Registry Server
Docker Build for Testing
Functional Testing Server
Execute Functional Test
(Black Box)
Initialize Test Env.
Integration Testing Server
Execute Integration Test
File Server
Copy Artifacts
Public Docker Registry Server
Docker Build for Production
Trigger
Return Reports
Download Files
Other Actions 1 2 3 4 6 5
IoTech to fill out some details and provide want/need list for DevOps/LF within the next couple of weeks

43. System Management MVP – owner Salim
Agree on requirements
Agree on what features are going to be in EdgeX and what is reserved for OS, 3rd party systems, other open source systems, etc.
Define what system management services need to be implemented as part of EdgeX (if any)
Define what system management hooks need to be implemented
Define any system management standards that will be followed/used in system management implementations (ex: LWM2M)
Stretch goal
Add some simple system manage hooks/capability into BaseService of EdgeX micro services – based on Dell Fuse work (for service start, stop …)

44. Additional Action Items
Tony, Janko, Andy, Jim and any other working group leads to identify resource issues by July 31st
Otherwise assumed that they have or can find resources to complete the MVP assigned to their WG
Jim to provide Kura/EdgeX feature comparison
Metric comparison not part of this study
Let Go services address EdgeX performance concerns and planning
Jim, Andy, Janko and others to stay in touch with marketing and event planning working groups
Provide cautionary guidance about demo needs that exceed tech community ability to deliver
Report to working groups on demo plans and technical needs

45. Action Items II Jim to find out from Jason about Test Bed commitments
Why orgs chosen and what commitments have been made?
Keith to work with TSC board to develop marketing and messaging around EdgeX event demos
July deadline for guidance
Keith to work with TSC board to determine time/place for next tech meeting
Concerns about coinciding with IoT Solutions World Congress in Barcelona
Too many people will have competing work with demos/booth staffing/etc.
Extending the trip at either end could be expensive/problematic

46. Action Items III
Keith to check on getting someone to sign up for Arm work
Keith/Jim work with Jason to get vendors to load/provide device hardware to blackbox testers (IoTech) and potentially test labs
Andy and Jim will work to set up maintainers and committers (by work group) within the next few weeks

47. Considered But Rejected MVP and Misc. Discussions during 2 days
Background
Considered But Rejected MVP and Misc. Discussions during 2 days

48. General MVP discussion items
No UI unless demo requirements dictate otherwise
“Support” requires formal testing on that OS/hardware (IoTech owner)
No Mac support, other Linux support or other version support by the working groups for this release
Support to 3rd parties and larger community if they can address these needs
Formal support in future releases
Current Dell Enlighted Demo numbers to be used to address scale (Dell owner)
California release to look at fault tolerance and security “hardening”
No currently planned EdgeX demos
Work with marketing and event planning groups to stay in front of demo needs
Considered but rejected doing performance testing on J9, Java 9, versus Kura, etc.
Go services is the answer – to be supported with some early performance #’s

49. Core/Supporting MVP discussion items
Model changes discussed but rejected
Implement dynamic configuration change callbacks rejected for MVP

50. Application MVP discussed items
How many and what cloud integration to provide
Went with path of least resistance for this first release
Support groups like IBM that might develop additional alternates
Changing default configuration was rejected for MVP
Like making Rules Engine direct recipient of data versus client of export distro
Additional formats, transformations, etc. considered but rejected
Drools change considered but rejected for MVP
Additional analytics considered but rejected for MVP
Hyperledger discussed but rejected for MVP

51. DS/DS SDK MVP discussion items
Considered but rejected additional DS for MVP
Considered but rejected additional SDK for MVP
Considered but rejected replacement of current DS/DS SDK tech like Spring Framework for MVP

52. Security MVP discussion items
Docker as a means to secure or contributing to security issues
Security certification

53. LF DevOps discussion GitHub Issues is currently in place
LF DevOps has 10 people to support the LF projects
Regarding build to Docker
Work to complete internal project to better define / setup the projects
Using Packer templates
Done next week; then start working on EdgeX Docker builds
EdgeX can help by defining the image that pulls the JAR file from the Maven Repos (use Maven dependency copy)
Automated testing outside of Linux will be difficult
LF based on 100% cloud solutions
Will need a hardware lab (look at Automotive Break project)
Code analysis/Static analysis
We may want to look at Sonar
Requires funding
Coverity allows a number of free checks per month but then gets expensive
They have no license checking tool for the code itself
They do have CLM Scan to do basic license check
GitHub Issues is currently in place
It is more clean/simple
JIRA costs for resoruces (not licensed per user)
JIRA also requires Linux ID or GitHub ID to access (already set up with Rocket Chat)
LF taking tech committee members through +/- of both at a later meeting.
Jenkins plugins must be part of Jenkins upstream system
No 3rd party Jenkins plugins allowed