Date   

EdgeX Barcelona MVP

James.White2@...
 

Good morning everyone.  Looking forward to next week’s technical meetings in London.  Really excited how far this community has already come and the energy that seems to be building with regard to EdgeX.

 

In this post, I would like to provide my take on what I believe is a realistic MVP set for our first release targeted for October and code named Barcelona.  This will be the focus for next week.  I have had discussion with a number of chairs and I want to give my perspective and attempt to set the table for some great discussion and decisions to be made next week.  This perspective comes from what I hear from the community, what I see as the community involvement to date, my knowledge of the current code base, and my estimates on the lift to accomplish the work being proposed.

 

There is a ton of work that could be done and a lot we want to accomplish long term.  The important question for this first release is what must be done and done by early October!!  So it is time reduce our appetites and lock in our focus.

 

I’d like to get your reaction and get a discussion going on these channels (along with Rocket Chat).  The more we can exchange on it now, the quicker and more successful our meeting next week can be.

 

I would like to thank John Walsh, Tony Espy, Janko Isidorovic, Andy Foster and many others that have started to layout their perspective working group goals and outline their MVPs.  My suggestions below are really taking from that work and intersected with my perspective.

Barcelona Goals and MVP as seen by the former Fuse Lead Architect

Barcelona Goals

·         Stabilize the platform

·         Build community understanding of the platform

·         General majority agreement on the architecture

·         General majority agreement on micro services and APIs

·         General majority agreement on the development of an open, platform independent, technology agnostic platform for the IoT/edge

·         General agreement on temporary performance targets

Minimum Viable Product (MVP)

General

·         Review and agree/adjust micro service APIs

·         Review and agree/adjust object models

·         Improve/increase documentation especially for areas of extension (DS SDK, Export Services)

·         Harden/stabilize the platform

o   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)

o   Handles errors and exceptions gracefully

o   Contains proper unit and integration tests (lacking in DS, supporting services and others)

o   Follows good coding standards, and is well documented (following some prescribed standard per programming paradigm)

o   Performs within the target measures established for Barcelona

§  Examine Kura in detail and adjust performance targets accordingly

·         Deliver Docker containers that run on Intel chip for Linux, Window, Mac

Stretch goals

·         Deliver Docker containers that run on Arm chip for Linux

Device Service / DS SDK

·         Deliver initial set of 7 Device Services based on Dell contributions (Modbus, BACnet, Bluetooth, SNMP, MQTT, Serial (Fischertechnik), Virtual)

·         Clean up SDK (and DSs)

o   Improve documentation

o   Merge device-sdk into SDK tools

o   Improve tooling (Eclipse Plugin)

o   Cleanup scheduler

Stretch goals

·         Remove redundant code from Device Services/SDK to shared libraries

·         Redo/refactor Bluetooth and BACnet DS to be single micro service

·         Additional DS provided by additional community participation

Core & Supporting Services

·         Clean up some minor issues

o   Logging OOM, Remove Device Manager, etc.

Stretch goals

·         Implement configuration callbacks (allowing for configuration changes dynamically without service restart

·         Provide first Go replacements for Data, MetaData, Command (Dell has a start to these already)

Applications (including Export Services, Rules Engine/Analytics)

·         Pick and provide at least one cloud connector (Azure IoT Hub has been prototyped by Dell)

·         Offer MQTT, REST, ZeroMQ export

·         Offer JSON, XML, CSV (not done yet) formats

·         Improve module for encryption options

·         Deal with potential number of readings, number of client scale problem

Stretch goals

·         Implement 2nd cloud connector (ex: Amazon Greengrass, Watson, ???)

·         Add additional format offering (ex: Haystack, etc.)

·         Add hyperledger export option

Security

·         In general, define the EdgeX security story but postpone a lot of implementation to California

·         WG to agree on requirements

·         WG to agree 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)

·         WG to define what EdgeX security service(s) need to be eventually implemented

·         WG to define what security hooks need to be added to the existing micro services

o   How and to which services would APIs communicate with

·         WG to define what standards, protocols, etc. are going to be adhered to and followed by EdgeX (ex:  IIC specs, OAuth tokens, etc.)

·         WG to provide guidance on how security features can/should be tested

Stretch goals

·         Add stubbed hooks into micro service code

System Management

·         In general, 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)

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, …)

Testing/QA

·         Insure part of code review/code check is to insure proper unit/integration tests for the code are provided (backed up by code coverage statistics)

·         Create a blackbox testing framework to insure the APIs between services are not broken and to be able to measure performance of a micro service and across multiple micro services to insure targets are achieved

·         Automate blackbox testing on all micro services with each build

Build/CI

·         Agree on a base set of policies and procedures around code check in, code approval, governance, etc.

·         Utilize the existing LF build process with some additions noted below.

·         Create Docker containers and push them to Docker Hub via the build process

·         Anoint a Bug Czar to setup a bug management process and monitor, track, and address incoming bugs (along with general support issues across media channels)

Stretch goals

·         Automate creation of ARM build/containers.

Event Demo

·         Create a working group to define the use case and demo presentation

·         Work with the community to get hardware, sensors, etc. donated for the demo

·         Create a minimal user interface for EdgeX (could be based on Dell Fuse UI)

As we discuss the MVP, we should also capture what items we believe don’t fit within the constraints of Barcelona and gets moved to California.

California Release Goals

·         Implement first security and system management services and tie to existing micro services

·         Improve performance

·         Introduce replacement services as appropriate (ex:  Go Core)

·         Demonstrate EdgeX in real world POC/Test Bed

Looking forward to the discussion.  Safe travels to all attending London meeting in person.

 

Jim White

Distinguished Engineer, Software Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


Invitation: EdgeX: Core WG Meeting @ Thu Aug 10, 2017 7:30am - 9am (PDT) (edgex-tsc-qa-test@lists.edgexfoundry.org)

Brett Preston
 

EdgeX: Core WG Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/437715614

Or iPhone one-tap (US Toll): +14086380968,,437715614# or +16465588656,,437715614#

Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
+1 855 880 1246 (US Toll Free)
+1 877 369 0926 (US Toll Free)
Meeting ID: 437 715 614
International numbers available: https://zoom.us/zoomconference?m=wxqTO4kWV7G5L2AKt-nuPjwg6x8WkM7D

When
Thu Aug 10, 2017 7:30am – 9am Pacific Time
Where
https://zoom.us/j/437715614 (map)
Calendar
edgex-tsc-qa-test@...
Who
(Guest list has been hidden at organizer's request)

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account edgex-tsc-qa-test@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Meeting agenda, minutes and recording of the call are now on line

James.White2@...
 

Thanks to all participants in today’s combined applications, core, device, test working group call.  We got a lot accomplished.

 

The agenda, action items and meeting notes and recording of the call are now available at:

 

https://wiki.edgexfoundry.org/display/FA/Core+Working+Groupf

 

Please advise on any revisions you would like to make to meeting notes.

Thanks

 

Jim White

Distinguished Engineer, Software Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


Re: [Edgex-tsc-applications] Meeting agenda, minutes and recording of the call are now on line

James.White2@...
 

Sorry – typo on the link.  Try

https://wiki.edgexfoundry.org/display/FA/Core+Working+Group

 

 

From: edgex-tsc-applications-bounces@... [mailto:edgex-tsc-applications-bounces@...] On Behalf Of White2, James
Sent: Thursday, August 10, 2017 12:03 PM
To: edgex-tsc-core@...; edgex-tsc-applications@...; edgex-tsc-device-services@...; edgex-tsc-qa-test@...
Subject: [Edgex-tsc-applications] Meeting agenda, minutes and recording of the call are now on line

 

Thanks to all participants in today’s combined applications, core, device, test working group call.  We got a lot accomplished.

 

The agenda, action items and meeting notes and recording of the call are now available at:

 

https://wiki.edgexfoundry.org/display/FA/Core+Working+Groupf

 

Please advise on any revisions you would like to make to meeting notes.

Thanks

 

Jim White

Distinguished Engineer, Software Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


Invitation: EdgeX: Core WG Meeting @ Weekly from 8am to 9am on Thursday from Thu Aug 17 to Thu Dec 28 (PDT) (edgex-tsc-qa-test@lists.edgexfoundry.org)

Brett Preston
 

EdgeX: Core WG Meeting

When
Weekly from 8am to 9am on Thursday from Thu Aug 17 to Thu Dec 28 Pacific Time
Where
https://zoom.us/j/201883906 (map)
Calendar
edgex-tsc-qa-test@...
Who
(Guest list has been hidden at organizer's request)
Will include Core, Applications, Device and Device SDK, DevOps, QA/Test, and Requirements and Strategy Working Groups

Hi there,

EdgeX Working Group 1 is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/201883906

Or iPhone one-tap (US Toll): +16468769923,,201883906# or +16699006833,,201883906#

Or Telephone:
Dial: +1 646 876 9923 (US Toll) or +1 669 900 6833 (US Toll)
+1 877 369 0926 (US Toll Free)
+1 877 853 5247 (US Toll Free)
Meeting ID: 201 883 906
International numbers available: https://zoom.us/zoomconference?m=Qqq7sz4L88ze6B1M1tTIMQkO-eZL20cy

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account edgex-tsc-qa-test@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Core working group meeting tomorrow

James.White2@...
 

All,


tomorrow we have a EdgeX Foundry Core Working group meeting.  The Applications WG, Core/Support Services WG, DS & DS SDK WG, and Test/QA/Build WG are all meeting jointly as part of this meeting right now.


Tomorrow's agenda includes:

 

Old business

1. SDK work and resource shortage issue - update and working plan

2. Project management tooling discussion

  a. info provided by Andrew Grimberg - leading candidates are GitHub Projects and Trello

  b. Action item to decide by next meeting

3. CI/Build/Test/QA/Process

  a. Contributors page done & Andy about to add more (let us know what else you think needs to be added)

  b. Andy working checkstyles with LF, Dell already using google styles as it makes updates

  c. Andy has setup working group to deal with GitHub Flow, Git Flow or Gerrit Flow question and regular LF meeting has been setup

4. Committers/Maintainers rules approved and committers approved by TSC (see

https://wiki.edgexfoundry.org/display/FA/Technical+Work+in+the+EdgeX+Foundry+Project).  Any further action needed?

5. Meeting invite consistency and policy.  Everyone should have rec'd message from Brett P about this.  Any further action needed?

a) Announce on #WGchannel on Rocket.Chat
b) Add meeting info to WG page on the Wiki
c) Email meeting info to the WG mail list
d) Send calendar invite to the WG mail list

6.  Barcelona demos - no update


New business

1. Go services - recommendation about coordinating the work and potential new releases

2.  Frequency of this meeting?  Every week or every other week?

3. Any new issues as raised by WG chairs




QA/Test and DevOps- Status Report

Andrew Foster
 

Status report for QA/Test and DevOps WSs in advance of 8/17 Core Working Group meeting

 

= What's Done =

  • Build/CI - build process now working (Docker build nearly complete)
  • Testing  - Postman “black box” integration tests now running on a local machine from GUI and have investigated running from command line using Newman
  • Tools - GitHub Issues selected as bug tracking tool
  • Collaboration - bi-weekly call established with LF DevOps experts to co-ordinate build/test/CI work, next call Tuesday 22nd August (12 noon, EDT)

 

=What’s Next=           

  • Build/CI
    • Complete Docker build
    • Integrate Checkstyle into Jenkins for automated code analysis against Google coding standards
    • Investigate documentation generation
  • Testing - integrate Postman tests into Jenkins
  • Tools - need to choose a Project Management tool to be used by individual WG and across the organization - choice between GitHub Projects (available for free with GitHub) and Trello (free options only)
  • Templates and Guidelines - circulate additional guidelines for branching model, committing code and versioning to QA/Test, DevOps and TSC WG mailing list + post to RocketChat for final comment and then TSC vote to adopt
  • Bi-weekly call established with LF DevOps experts to co-ordinate build/test/CI work, next call Tuesday 22nd August (12 noon, EDT)

 

= Issues =

None

 

 

 

Product Director

Tel: +44 (0)7703 006 379

 


EdgeX Versioning

Andrew Foster
 

Folks,

We have been discussing software versioning schemes for EdgeX and have arrived at the conclusion that a version identifier is not only required to support the overall consolidated bundle of EdgeX components but also individual microservices will also need their own version numbers to support the fact that they will have different lifecycles and evolve/change at a different pace from each other.

The key part of the discussion has been focused on the degree to which the scheme we choose infers the significance of any changes or compatibility between releases.  If individual microservices have their own version numbers then less emphasis needs to be put on the EdgeX consolidated version identifier to infer any underling change, and instead of having a traditional sequence identifier (e.g. EdgeX 1.0) we can use an alternative simpler identifier, for example using the date of the release (e.g EdgeX 17.08) as the idnetifier.

For the version number for each individual microservice I believe that we need to decide between:

  1. Semantic versioning (http://semver.org/) - which prescribes a set of rules and requirements that dictate how version numbers are assigned and incremented. For this scheme to work, a software product must declare a public API. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. The key point of semantic versioning is that for all organizations who adopt sematic versioning the  same rules apply to all projects.

For example I believe that semantic versioning would be applied to EdgeX microservices as follows:

  • We cut a release of EdgeX and it contains microservice A with version 1.0.0
  • Make a bug fix to microservice A with no API changes and its version changes to 1.0.1
  • Make some functional changes to microservices A, perhaps even add an additional external API but do not change any other existing APIs, its version changes to 1.1.0 to indicate the addition of new functionality but not a change that affects backwards compatibility
  • We decide to deprecate or change the signature of an external API, its version would change to 2.0.0 as backwards compatibility is broken (and the process repeats)
  • By comparing the version numbers for each microservice between EdgeX releases then the significance of any changes could be inferred and then the release notes consulted if necessary to see details of any specific changes (in particular for the cases where backwards compatibility has been broken). 
  1. Change significance – alternatively we could adopt a less prescriptive scheme that provides the ability to tailor the rules of the versioning identifier significance to the specific needs of the project. Sequence-based identifiers (e.g. X.Y.Z) can still be used to convey the significance of changes between releases: changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance.  In this case identifying issues such as backwards compatibility between releases would be determined from the specific significance rules that the project adopts when the sequence identifier changes.

The default proposal is to adopt semantic versioning for the EdgeX microservices.  I would like feedback from the community on your views of the pros and cons of the two approaches before putting a recommendation to a vote.

Thanks for your input.

Andy Foster

QA and Test WG Chair

 

 

 

 

 

 

 

https://en.wikipedia.org/wiki/Software_versioning

1.      We cut a release of EdgeX and it contains microservice A with at version 1.0.0

2.      Make a bug fix to microservice A with no API changes and its version changes to 1.0.1

2.      Make some changes functional changes to microservices A, perhaps even add an additional external API but does not change any other existing APIs, its version changes to 1.1.0 to indicate the addition of new functionality but not a change that affects backwards compatibility

3.      We decide to deprecate or change the signature of an external API, its version would change to 2.0.0 as backwards compatibility is broken (and the process repeats)

There would still be a higher level version/identifier for each consolidated EdgeX release, but within each release there would be an individual version number for each microservice. By comparing the version numbers for each microservice between EdgeX releases then the significance of any changes could be inferred and then the release notes consulted if necessary to see details of any specific changes (in particular for the cases where backwards compatibility has been broken). 

Andy

QA and Test Chair

 

 

Product Director

Tel: +44 (0)7703 006 379

 


Re: [Edgex-tsc-core] EdgeX Versioning

Keith Steele <keith@...>
 

Andy
We can't have a free for all here. Surely we have to be prescriptive to avoid chaos in terms potentially differing versioning policies?
I strongly advise we adopt one agreed meaning for versioning ie semantic versioning.
Regards
Keith

On 18 August 2017 at 16:04, Andrew Foster <andy@...> wrote:

Folks,

We have been discussing software versioning schemes for EdgeX and have arrived at the conclusion that a version identifier is not only required to support the overall consolidated bundle of EdgeX components but also individual microservices will also need their own version numbers to support the fact that they will have different lifecycles and evolve/change at a different pace from each other.

The key part of the discussion has been focused on the degree to which the scheme we choose infers the significance of any changes or compatibility between releases.  If individual microservices have their own version numbers then less emphasis needs to be put on the EdgeX consolidated version identifier to infer any underling change, and instead of having a traditional sequence identifier (e.g. EdgeX 1.0) we can use an alternative simpler identifier, for example using the date of the release (e.g EdgeX 17.08) as the idnetifier.

For the version number for each individual microservice I believe that we need to decide between:

  1. Semantic versioning (http://semver.org/) - which prescribes a set of rules and requirements that dictate how version numbers are assigned and incremented. For this scheme to work, a software product must declare a public API. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. The key point of semantic versioning is that for all organizations who adopt sematic versioning the  same rules apply to all projects.

For example I believe that semantic versioning would be applied to EdgeX microservices as follows:

  • We cut a release of EdgeX and it contains microservice A with version 1.0.0
  • Make a bug fix to microservice A with no API changes and its version changes to 1.0.1
  • Make some functional changes to microservices A, perhaps even add an additional external API but do not change any other existing APIs, its version changes to 1.1.0 to indicate the addition of new functionality but not a change that affects backwards compatibility
  • We decide to deprecate or change the signature of an external API, its version would change to 2.0.0 as backwards compatibility is broken (and the process repeats)
  • By comparing the version numbers for each microservice between EdgeX releases then the significance of any changes could be inferred and then the release notes consulted if necessary to see details of any specific changes (in particular for the cases where backwards compatibility has been broken). 
  1. Change significance – alternatively we could adopt a less prescriptive scheme that provides the ability to tailor the rules of the versioning identifier significance to the specific needs of the project. Sequence-based identifiers (e.g. X.Y.Z) can still be used to convey the significance of changes between releases: changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance.  In this case identifying issues such as backwards compatibility between releases would be determined from the specific significance rules that the project adopts when the sequence identifier changes.

The default proposal is to adopt semantic versioning for the EdgeX microservices.  I would like feedback from the community on your views of the pros and cons of the two approaches before putting a recommendation to a vote.

Thanks for your input.

Andy Foster

QA and Test WG Chair

 

 

 

 

 

 

 

https://en.wikipedia.org/wiki/Software_versioning

1.      We cut a release of EdgeX and it contains microservice A with at version 1.0.0

2.      Make a bug fix to microservice A with no API changes and its version changes to 1.0.1

2.      Make some changes functional changes to microservices A, perhaps even add an additional external API but does not change any other existing APIs, its version changes to 1.1.0 to indicate the addition of new functionality but not a change that affects backwards compatibility

3.      We decide to deprecate or change the signature of an external API, its version would change to 2.0.0 as backwards compatibility is broken (and the process repeats)

There would still be a higher level version/identifier for each consolidated EdgeX release, but within each release there would be an individual version number for each microservice. By comparing the version numbers for each microservice between EdgeX releases then the significance of any changes could be inferred and then the release notes consulted if necessary to see details of any specific changes (in particular for the cases where backwards compatibility has been broken). 

Andy

QA and Test Chair

 

 

Product Director

Tel: +44 (0)7703 006 379

 


_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core



Agenda for Core Working Group Meeting tomorrow (8/24 - 8am PDT)

James.White2@...
 

Proposed agenda for tomorrow's meeting.  Let me know if you have other agenda items you would like to add/discuss.  WG chairs are reminded to post their groups status report to the mailer list before the meeting.


Thanks


Jim White
Distinguished Engineer, Software Architect
Dell Technologies | End User Computing, Chief Technology Office (EUC CTO)
Office +1 512-723-6139, mobile/text +1 612-916-6693
james_white2@...


Old Business

SDK update

  • Feedback from Cloud and others provided
  • requirements out for review
  • design forthcoming
  • refactor follows that
  • probably will not all get done by Oct 1

Project Management Tool

  • Final discussion and decision
  • Two primary choices:  GitHub Project Trello

Build/CI

  • Checkstyles - Contributors page update [issue complete]
  • Build process update (Docker containers)
  • GitHub basics, branching, etc. Contributors page
  • Versioning, etc. (Tony and Andy work) -is this considered finalized and complete?

Barcelona Demos

  • No center stage demo
  • Other demo needs?
  • Dell UI ready for use (NDA required)

Go Services

  • Meeting on styles, guidance, etc – Sept 15
  • Have deeper dive meetings starting in Oct
  • Rocket Channel setup
  • TSC informed of Go Preview (Jan 31)

New Business

Test/QA

  1. IoTech team nearing completion on test framework (integration tests) using Postman



GitHub Projects Versus Trello

James.White2@...
 

Part of the Core WG agenda tomorrow is to finalize a decision around choice in project management/task tool.  The two leading candidates that have been presented are GitHub Projects and Trello.  I found the following web sites useful in providing some comparisons.  First one in particular I thought recent and very useful


https://medium.com/@yeltzland/trello-vs-github-projects-power-vs-simplicity-d237c0322c9b


https://gist.github.com/jsanders/7c813c5d7c561a37af94


For those in the Core WG call tomorrow, please come prepared to provide your opinion and vote - and report on any direct use you have had with these tools.


Thanks

Jim


FW: QA/Test and DevOps- Status Report

Andrew Foster
 

Status report for QA/Test and DevOps WGs in advance of 8/24 Core Working Group meeting

 

= What's Done =

  • Build/CI  - Docker build close to completion, possible upgrade to Docker 17.05
  • Build CI - Jim White to look at adding Checkstyle Maven plugin to the pom.xml file in core/supporting services and see if he can find out how the warn/error option is set (via pom or in Jenkins, etc.)
  • Testing - Postman integration tests running, IOTech looking into how to trigger them from Jenkins
  • Template and Guidelines - proposed branching model circulated for comment - Tony Espy has provided some final recommendations around the use of GitHub Flow for the groups review

 

=What’s Next=           

  • Build/CI - Investigate documentation generation
  • Templates and Guidelines - circulate additional contributors guidelines (GitHib basics, committing code guidelines – commits, message style guide, branching conventions, merging) to QA/Test, DevOps and TSC WG mailing list + post to RocketChat for comment

 

= Issues =

None

 

 

Product Director

Tel: +44 (0)7703 006 379

 


Working Group Meeting minutes and recording

James.White2@...
 

Today's core working group (including core/support, applications, device services/SDK, test/QA working groups) meeting recording and minutes are available at https://wiki.edgexfoundry.org/display/FA/Core+Working+Group.


Significant Action items include:

  • Request all with interest in device services and SDK to review Device Services Requirements at https://wiki.edgexfoundry.org/display/FA/Architecture--Device+Services+Microservices
  • Decision made to use GitHub Projects for project management and to-do task tracking.  Jim to work with LF to get in place and set up the boards
  • Andy to publish adopted/accepted work on GitHub basics, branching, etc (based on message from Tony) to Contributors page in the Wiki
  • Tony to provide proposal for project versioning schema in emailer for final vote next week
  • Request for anyone with IoT Solution World Demos that involve EdgeX to provide working group info on needs ASAP


Thanks


Jim White
Distinguished Engineer, Software Architect
Dell Technologies | End User Computing, Chief Technology Office (EUC CTO)
Office +1 512-723-6139, mobile/text +1 612-916-6693
james_white2@...



 


Canceled Event: EdgeX: Core WG Meeting @ Thu Oct 5, 2017 8am - 9am (PDT) (edgex-tsc-qa-test@lists.edgexfoundry.org)

Brett Preston
 

This event has been canceled and removed from your calendar.

EdgeX: Core WG Meeting

When
Thu Oct 5, 2017 8am – 9am Pacific Time
Where
https://zoom.us/j/201883906 (map)
Calendar
edgex-tsc-qa-test@...
Who
(Guest list has been hidden at organizer's request)
Will include Core, Applications, Device and Device SDK, DevOps, QA/Test, and Requirements and Strategy Working Groups

Hi there,

EdgeX Working Group 1 is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/201883906

Or iPhone one-tap (US Toll): +16468769923,,201883906# or +16699006833,,201883906#

Or Telephone:
Dial: +1 646 876 9923 (US Toll) or +1 669 900 6833 (US Toll)
+1 877 369 0926 (US Toll Free)
+1 877 853 5247 (US Toll Free)
Meeting ID: 201 883 906
International numbers available: https://zoom.us/zoomconference?m=Qqq7sz4L88ze6B1M1tTIMQkO-eZL20cy

Invitation from Google Calendar

You are receiving this courtesy email at the account edgex-tsc-qa-test@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Project status via GitHub Projects

James.White2@...
 

EdgeX’ers – the working group chairs have been using these mailing lists to provide weekly updates to the community of ongoing work.  


As GitHub Projects has now been setup for the project, it will used to track the current tasks and progress toward Barcelona and other releases.  As a member of the community (you will need to login to GitHub to see the project boards), you can get an up to the minute status of any of the working groups and the tasks they have in front of them via the GitHub Projects task boards.  You can find out what the working groups are doing, what’s left to be done, and what has already been accomplished for any release in a dedicated project board for each group. 


Check out the EdgeX project boards at:  https://github.com/orgs/edgexfoundry/projects



Jim White
Core Services Chair
james_white2@...



Re: [Edgex-devel] Project status via GitHub Projects

Drasko DRASKOVIC <drasko@...>
 

Hi Jim,
looks like the boards have not been set-up with appropriate permissions.

I think you should either make them public or add us all to EdgeX
GitHub organization :).

BR,
Drasko

On Wed, Aug 30, 2017 at 9:55 PM, <James.White2@...> wrote:
EdgeX’ers – the working group chairs have been using these mailing lists to
provide weekly updates to the community of ongoing work.


As GitHub Projects has now been setup for the project, it will used to track
the current tasks and progress toward Barcelona and other releases. As a
member of the community (you will need to login to GitHub to see the project
boards), you can get an up to the minute status of any of the working groups
and the tasks they have in front of them via the GitHub Projects task
boards. You can find out what the working groups are doing, what’s left to
be done, and what has already been accomplished for any release in a
dedicated project board for each group.


Check out the EdgeX project boards at:
https://github.com/orgs/edgexfoundry/projects



Jim White
Core Services Chair
james_white2@...



_______________________________________________
EdgeX-Devel mailing list
EdgeX-Devel@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-devel


Core Services Working Group meeting tomorrow 8am PDT

James.White2@...
 

Reminder that we have the EdgeX core group meeting (combine applications, core/supporting services, device services/SDK, Test/QA, Build/CI working groups) tomorrow at 8am PDT. Hope you can join us. Here is the tentative agenda:


Old Business
SDK Update: cleanup of requirements and working on design
PM Tool:
•GitHub Projects setup, tasks added, issues with access begin addressed
•Thanks Janko for first board setup template
•Any comments/issues with regard to board/task organization? Any standards we want to follow?
Build/CI
•Docker container build still waiting on LF (Docker 17.05)
•Coding guidelines: Andy has draft ready for approval
•Versioning: Tony Espy provided versioning document via email (https://lists.edgexfoundry.org/pipermail/edgex-tsc-core/2017-August/000016.html). Discussion and vote on adoption.
Barcelona Demos
•Seeking any new news or needs for Oct 3-5 meeting on demos
Go Services
•Reminder of meeting on Sept 15th.
•Any new updates/info
Test/QA
•Progress on Blackbox/integration testing (Andy)
New Business
•Any opens or new business?


QA/Test and DevOps- Status Report

Andrew Foster
 

Status report for QA/Test and DevOps WGs in advance of 8/31 Core Working Group meeting

 

= What's Done =

  • Build/CI  - Docker build close to completion, waiting on Docker 17.05 upgrade
  • Build/CI - Jim White has added Checkstyle Maven plugin to the pom.xml file in core/supporting services
  • Testing - Postman integration tests running and now being triggered from IOTech’s Jenkins server
  • Templates and Guidelines - code contribution guidelines revised to reflect feedback from EdgeX community and LF
  • Other – initial MVP QA/Test (https://github.com/orgs/edgexfoundry/projects/4 ) and Build/CI/Devops (https://github.com/orgs/edgexfoundry/projects/5 ) tasks and assignments added to respective GitHub Project Boards

 

=What’s Next=           

  • Build/CI
    • Trigger additional Integration test groups from Jenkins (command, core data and meta data currently being executed), process results in JUnit and use Jenkins post process plugin too publish results,  work with LF to get this integrated into EdgeX Build/CI pipeline
    • Investigate documentation generation
  • Testing - review integration test coverage and create plan for improvements
  • Templates and Guidelines - add new code contribution guidelines to Wiki (Introducing GitHub, EdgeX GitHub Getting Started, GitHub Flow, Branching Conventions, Commits, Commit Messages, Merging)

= Issues =

None

 

 

Product Director

Tel: +44 (0)7703 006 379

 


Coding Guidelines and Versioning

James.White2@...
 

EdgeX’ers,

as a result of today’s EdgeX Core Working Groups meeting, coding guidelines and a project microservice versioning scheme were unanimously approved and adopted.  The coding guidelines are considered tentatively approved awaiting any significant input from the community (you) until Sept 6th.


At https://wiki.edgexfoundry.org/display/FA/Contributor%27s+Guide you can find both the coding guidelines document (top of the Wiki Page) and Versioning guidance/scheme (at the bottom of the Wiki Page).


Thanks to Andy Foster (IoTech) for pulling together the coding guidelines and Tony Espy (Canonical) for providing the versioning recommendation.



EdgeX Core Working Group Reminder

James.White2@...
 

Reminder that the Core Working Group Meeting is at 11am EST (10am CST and 8am PST) Thursday.  Lots to discuss at tomorrow's Core Working Group meeting.  Please join us if you can.
Old Business
SDK Update:  cleanup of requirements and working on design
PM Tool
•GitHub Projects security issue (see RocketChat for Jeremy’s note on issue and work around)
  oNeed group decision:  do we move to recommended LF plan (projects under fake repos) or go to Trello?  We have to re do the project task setup either way.
Build/CI
•Docker container build update
•Coding guidelines:  Andy provided draft for review on contributor’s page
  oPer last week, barring no significant updates/modification, considered adopted and ratified for use
  oAny other comments (Tony E?).
  oCode sign offs (seems to be an issue we need to address more)
•Versioning:  Guide posted to Contributor’s page last week (based on Tony Espy email and group adoption)
  oAny other actions on this or can it be close?
 Test/QA
•Progress on Blackbox/integration testing (Andy)
Barcelona Demos
•Seeking any new news or needs for Oct 3-5 meeting on demos
  o Michael Hathaway
  o Rodney (Beechwoods)
Go Services
•Reminder of meeting on Sept 15th.
Documentation
•IoTech introduced the topic last week and had some thoughts to share about inline code documentation and user documentation.
New Business
Release Cuts
•Conversation during DevOps meeting this week.
•LF recommends Open Daylight and ONLP projects as examples of how to do.
•Discussion and action items
Barcelona Face-to-face meeting
•Proposed agenda at https://wiki.edgexfoundry.org/display/FA/5+October+2017%3A+IOT+Solutions+World+Congress+Barcelona
•Discussion about proposed agenda; additions, removals
Chair position Elections/extensions
•Proposal before TSC to extend all until end of this calendar year
•Per TSC meeting