Topics

Core WG Meeting -> covering Device Service WG items this week

James.White2@...
 

All,

 

Heads up:  Core WG time this week will be used for Device Service WG issues.  – Due to the backlog of device service issues that are impactful to a number of Fuji release work streams (including Core WG items), we are asking Device Service WG attendees to attend the Core WG meeting on Thursday (10am Central time) if possible.  Core WG members, the issues being considered are also those that impact Core work and so are still important to you as well.  BTW - Trevor and Steve are on board with this use of this meeting time this week.

 

The issues that I would like to try to tackle in this special Device Service meeting (in order of priority) include the following:

 

  1. Value Descriptors created only in core – an issue discussed at Seoul and added to our Fuji release.  Trevor has the details (he just sent out an email) and will cover issue in the meeting and see if we can get design consensus
  2. Provision Watchers/blacklists design – based on the call today, I think we should try to finalize this design sooner versus later and I don’t think we are too far from it.  Although I asked Steve and Iain to take the lead, I’d like to propose the following in the group and see if we can get consensus:
    1. Keep the Provision Watcher schema with wild cards as is (or was with Java).  We may have to do some work on the way the scan lists are specified to provide cleaner/better ways of specifying scan ranges/scopes, but we can work that as we go forward.  Also remove the full device profile from the Provision Watcher (just have the name)
    2. Use the internal scheduler (replacing use of the support scheduler) to trigger scans
    3. As Tony suggested, not have a blacklist/whitelist, but use changes to the Provision Watcher scan list to exclude/include.  If you un-provision a device and don’t want it to be picked back up in the next scan, include this in a Provision Watcher update before removing the device
  3. Bootstrapping additions per Daniel Harms message (Per-Device bootstrapping function in EdgeX DS SDK for Fuji release).
  4. What to do with the Mindsphere DS contributed by WiPro in holding

 

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

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

james_white2@...

 

Iain Anderson
 



On 10/06/2019 19:28, James.White2@... wrote:
  1. Provision Watchers/blacklists design – based on the call today, I think we should try to finalize this design sooner versus later and I don’t think we are too far from it.  Although I asked Steve and Iain to take the lead, I’d like to propose the following in the group and see if we can get consensus:
    1. Keep the Provision Watcher schema with wild cards as is (or was with Java).  We may have to do some work on the way the scan lists are specified to provide cleaner/better ways of specifying scan ranges/scopes, but we can work that as we go forward.  Also remove the full device profile from the Provision Watcher (just have the name)
    2. Use the internal scheduler (replacing use of the support scheduler) to trigger scans
Is what we want here to allow all of:
i) scans triggered by hitting the rest endpoint (as now) (existing config setting to disable)
ii) scans triggered by an internal scheduler (new config setting for interval)
iii) scans triggered by a DS implementation in response to stimuli particular to its device type (any config would be DS-specific)

  1. Bootstrapping additions per Daniel Harms message (Per-Device bootstrapping function in EdgeX DS SDK for Fuji release).
State of play on this is here: https://github.com/edgexfoundry/device-sdk-go/issues/276

I'll copy Daniel's email onto the issue.

Regards,
Iain

James.White2@...
 

That is a good question/observation Ian.  Definitely need i and ii.  Anyone have an example of iii?  If so, could the DS just hit its own endpoint?  In other words do i?

 

Is what we want here to allow all of:
i) scans triggered by hitting the rest endpoint (as now) (existing config setting to disable)
ii) scans triggered by an internal scheduler (new config setting for interval)
iii) scans triggered by a DS implementation in response to stimuli particular to its device type (any config would be DS-specific)

 

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> On Behalf Of Iain Anderson
Sent: Tuesday, June 11, 2019 8:05 AM
To: EdgeX-TSC-Device-Services@...
Subject: Re: [Edgex-tsc-device-services] Core WG Meeting -> covering Device Service WG items this week

 

[EXTERNAL EMAIL]

 

On 10/06/2019 19:28, James.White2@... wrote:

  1. Provision Watchers/blacklists design – based on the call today, I think we should try to finalize this design sooner versus later and I don’t think we are too far from it.  Although I asked Steve and Iain to take the lead, I’d like to propose the following in the group and see if we can get consensus:
    1. Keep the Provision Watcher schema with wild cards as is (or was with Java).  We may have to do some work on the way the scan lists are specified to provide cleaner/better ways of specifying scan ranges/scopes, but we can work that as we go forward.  Also remove the full device profile from the Provision Watcher (just have the name)
    2. Use the internal scheduler (replacing use of the support scheduler) to trigger scans

Is what we want here to allow all of:
i) scans triggered by hitting the rest endpoint (as now) (existing config setting to disable)
ii) scans triggered by an internal scheduler (new config setting for interval)
iii) scans triggered by a DS implementation in response to stimuli particular to its device type (any config would be DS-specific)


  1. Bootstrapping additions per Daniel Harms message (Per-Device bootstrapping function in EdgeX DS SDK for Fuji release).

State of play on this is here: https://github.com/edgexfoundry/device-sdk-go/issues/276

I'll copy Daniel's email onto the issue.

Regards,
Iain

Iain Anderson
 

Yes, we could expose the functionality that implements the endpoint. Or provide a version of the AddDevice call that filters according to Provision Watcher rules. Or both tbh.

Regards,
Iain

On 11/06/2019 14:34, James.White2@... wrote:

That is a good question/observation Ian.  Definitely need i and ii.  Anyone have an example of iii?  If so, could the DS just hit its own endpoint?  In other words do i?

 

Is what we want here to allow all of:
i) scans triggered by hitting the rest endpoint (as now) (existing config setting to disable)
ii) scans triggered by an internal scheduler (new config setting for interval)
iii) scans triggered by a DS implementation in response to stimuli particular to its device type (any config would be DS-specific)

 

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> On Behalf Of Iain Anderson
Sent: Tuesday, June 11, 2019 8:05 AM
To: EdgeX-TSC-Device-Services@...
Subject: Re: [Edgex-tsc-device-services] Core WG Meeting -> covering Device Service WG items this week

 

[EXTERNAL EMAIL]

 

On 10/06/2019 19:28, James.White2@... wrote:

  1. Provision Watchers/blacklists design – based on the call today, I think we should try to finalize this design sooner versus later and I don’t think we are too far from it.  Although I asked Steve and Iain to take the lead, I’d like to propose the following in the group and see if we can get consensus:
    1. Keep the Provision Watcher schema with wild cards as is (or was with Java).  We may have to do some work on the way the scan lists are specified to provide cleaner/better ways of specifying scan ranges/scopes, but we can work that as we go forward.  Also remove the full device profile from the Provision Watcher (just have the name)
    2. Use the internal scheduler (replacing use of the support scheduler) to trigger scans

Is what we want here to allow all of:
i) scans triggered by hitting the rest endpoint (as now) (existing config setting to disable)
ii) scans triggered by an internal scheduler (new config setting for interval)
iii) scans triggered by a DS implementation in response to stimuli particular to its device type (any config would be DS-specific)


  1. Bootstrapping additions per Daniel Harms message (Per-Device bootstrapping function in EdgeX DS SDK for Fuji release).

State of play on this is here: https://github.com/edgexfoundry/device-sdk-go/issues/276

I'll copy Daniel's email onto the issue.

Regards,
Iain


Iain Anderson
 

Hi all,
Further to the discussion on ProvisionWatchers in the Core WG this week, we think the following changes to the existing model would be useful:

1) Replace the OperatingState field in the PW with a new enum with three possible results:

i) IGNORE - matching devices are not added.
ii) LOCK - matching devices are added in the Locked AdminState.
iii) UNLOCK - matching devices are added in the Unlocked AdminState.

If a device matches multiple PWs the most restrictive is applied.
We think that AdminState is more applicable than OperatingState, and the ignore option allows for blacklisting.

2) Allow a wildcard in the DeviceService field of the PW

This permits easier management in deployments where a device may move out of range of one device service and into another. It puts a requirement on the /provisionwatcher/servicename/{servicename} endpoint of core-metadata to perform wildcard matching.

Regards,
Iain