Date   
Cancelled Event: EdgeX TSC Meeting (Weekly) - Wednesday, 25 December 2019 #cal-cancelled

EdgeX-TSC@lists.edgexfoundry.org Calendar <EdgeX-TSC@...>
 

Cancelled: EdgeX TSC Meeting (Weekly)

This event has been cancelled.

When:
Wednesday, 25 December 2019
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/983155298

Organizer: EdgeX-TSC@...

Description:
EdgeX TSC Meeting: To discuss top-level technical discussions. Meeting content posted to TSC Wiki.
Meeting Lead: Keith Steele, EdgeX TSC Chair, keith@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

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

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: 983 155 298
    International numbers available: https://zoom.us/zoomconference?m=mkFexUxEcqHlvXHw53PqScTDRvS48PiQ

Re: EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

Gregg, James R
 

IT-18564 Nexus3 Life Cycle Policy changes has been submitted to request the new LCP on Nexus3

Re: Move REST device service out of -holding

Corrion, Bradley W
 

+1 - one of the key results of the Hackathon prep!

On 12/18/19, 9:01 AM, "EdgeX-TSC@... on behalf of Iain Anderson" <EdgeX-TSC@... on behalf of iain@...> wrote:

TSC Members,
I'm seeking approval to move the REST device service (device-rest-go)
out of the -holding project and into edgexfoundry.

https://github.com/edgexfoundry-holding/device-rest-go

The service provides an easy way for 3rd party applications such as
Point of Sale, CV Analytics, etc. to push data into EdgeX via the REST
protocol.

This service has been reviewed by Tony Espy in the last fortnight with
regard to the acceptability criteria outlined in the process for new DSs
at https://wiki.edgexfoundry.org/x/_QHiAQ and it was agreed in this
week's working group meeting that the service be accepted.

Please approve this request with a vote of +1.

Regards,
Iain

Re: Move REST device service out of -holding

Michael Estrin
 

+1
________________________________________
From: EdgeX-TSC@... <EdgeX-TSC@...> on behalf of Iain Anderson <iain@...>
Sent: Wednesday, December 18, 2019 6:01 AM
To: edgex-tsc@...
Subject: [Edgex-tsc] Move REST device service out of -holding

[EXTERNAL EMAIL]

TSC Members,
I'm seeking approval to move the REST device service (device-rest-go)
out of the -holding project and into edgexfoundry.

https://github.com/edgexfoundry-holding/device-rest-go

The service provides an easy way for 3rd party applications such as
Point of Sale, CV Analytics, etc. to push data into EdgeX via the REST
protocol.

This service has been reviewed by Tony Espy in the last fortnight with
regard to the acceptability criteria outlined in the process for new DSs
at https://wiki.edgexfoundry.org/x/_QHiAQ and it was agreed in this
week's working group meeting that the service be accepted.

Please approve this request with a vote of +1.

Regards,
Iain

Re: Move REST device service out of -holding

espy
 

+1

On 12/18/19 7:01 AM, Iain Anderson wrote:
TSC Members,
I'm seeking approval to move the REST device service (device-rest-go) out of the -holding project and into edgexfoundry.

https://github.com/edgexfoundry-holding/device-rest-go

The service provides an easy way for 3rd party applications such as Point of Sale, CV Analytics, etc. to push data into EdgeX via the REST protocol.

This service has been reviewed by Tony Espy in the last fortnight with regard to the acceptability criteria outlined in the process for new DSs at https://wiki.edgexfoundry.org/x/_QHiAQ and it was agreed in this week's working group meeting that the service be accepted.

Please approve this request with a vote of +1.

Regards,
Iain


EdgeX TSC Meeting (Weekly) - Wed, 12/18/2019 #cal-notice

EdgeX-TSC@lists.edgexfoundry.org Calendar <noreply@...>
 

EdgeX TSC Meeting (Weekly)

When:
Wednesday, 18 December 2019
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/j/983155298

Organizer:
EdgeX-TSC@...

Description:
EdgeX TSC Meeting: To discuss top-level technical discussions. Meeting content posted to TSC Wiki.
Meeting Lead: Keith Steele, EdgeX TSC Chair, keith@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

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

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: 983 155 298
    International numbers available: https://zoom.us/zoomconference?m=mkFexUxEcqHlvXHw53PqScTDRvS48PiQ

Re: Move REST device service out of -holding

Trevor.Conn@...
 

+1

-----Original Message-----
From: EdgeX-TSC@... <EdgeX-TSC@...> On Behalf Of Iain Anderson
Sent: Wednesday, December 18, 2019 6:01 AM
To: edgex-tsc@...
Subject: [Edgex-tsc] Move REST device service out of -holding


[EXTERNAL EMAIL]

TSC Members,
I'm seeking approval to move the REST device service (device-rest-go) out of the -holding project and into edgexfoundry.

https://github.com/edgexfoundry-holding/device-rest-go

The service provides an easy way for 3rd party applications such as Point of Sale, CV Analytics, etc. to push data into EdgeX via the REST protocol.

This service has been reviewed by Tony Espy in the last fortnight with regard to the acceptability criteria outlined in the process for new DSs at https://wiki.edgexfoundry.org/x/_QHiAQ and it was agreed in this week's working group meeting that the service be accepted.

Please approve this request with a vote of +1.

Regards,
Iain

Upcoming Event: EdgeX TSC Meeting (Weekly) - Wed, 12/18/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC@lists.edgexfoundry.org Calendar <EdgeX-TSC@...>
 

Reminder: EdgeX TSC Meeting (Weekly)

When: Wednesday, 18 December 2019, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/983155298

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC@...

Description: EdgeX TSC Meeting: To discuss top-level technical discussions. Meeting content posted to TSC Wiki.
Meeting Lead: Keith Steele, EdgeX TSC Chair, keith@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

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

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: 983 155 298
    International numbers available: https://zoom.us/zoomconference?m=mkFexUxEcqHlvXHw53PqScTDRvS48PiQ

Re: Issue/project management proposal (architecture WG)

Michael Hall <mhall119@...>
 

Milestones are also a good way of tracking "How many things are we trying to get done for $Release" and "How is our progress towards $Release", both of which are important from a release management perspective. Ideally there would be an issue created and assigned to a release milestone for every item that was agreed to in the last F2F.

There are also several scripts in the wild that will create burn-down charts based on issues in milestones, so the project could see if they are closing issues on a fast enough pace to reach the release goals, of if some things will need to be pushed back to a future release. Given previous discussions about this need, I think this would be beneficial to EdgeX Foundry to implement.

Michael Hall
mhall119@...
On 12/16/19 7:23 PM, espy wrote:

On 12/16/19 2:14 PM, Bryon Nevis wrote:

Posting this document for feedback from the Architects WG prior to bringing this to TSC officially.

As discussed in the Geneva F2F we are looking to get a better handle on project management using the currently available tools (i.e. GitHub).  I have attached a document that reverse-engineers what I perceive as the current business process around GitHub issue and project management features, based on my own biases and early reviews and discussion with DevOps, Security WG, and one architecture WG meeting.  The goal is to obtain agreement from the various working groups on the underlying meaning of the various fields/labels so that we can more effectively communicate and plan, and to then propose this for TSC-level adoption.

The current hot button issue in this document is what the "Milestone" field means and if it should be used at all. (I personally have gone back and forth.)  

In other bug trackers I've used, milestones usually represent some stage of a release with an associated date attached (eg. Geneva-Feature-Freeze, Geneva-Beta, ...), and when set, indicate a commitment to fixing the bug/issue by that date.

We've been somewhat overloading our usage of release labels. In some cases we've used it to indicate that a bug/issue exists in the specified release(s), and in some cases we've used it to indicate that the bug would be fixed in the indicated release. I don't think we can have it both ways.

My proposal would be that a release label means the bug exists in the release(s) specified, and that a milestone means the bug/issue/feature has been committed for the release. As pointed out, if we close a bug that has multiple release labels, we may need to create a copy of the issue for the release(s) for which a fix has yet to land.

Other open is whether this document should also discuss business process around pull request management.

My preference would be that PR process management be kept separate.

Regards,
/tony

Please provide feedback to me or this mail list using the same subject.  If I have missed anyone who feels they should be listed in the author's list please let me know--I would like to give credit to everyone involved in defining our process.





Move REST device service out of -holding

Iain Anderson
 

TSC Members,
I'm seeking approval to move the REST device service (device-rest-go) out of the -holding project and into edgexfoundry.

https://github.com/edgexfoundry-holding/device-rest-go

The service provides an easy way for 3rd party applications such as Point of Sale, CV Analytics, etc. to push data into EdgeX via the REST protocol.

This service has been reviewed by Tony Espy in the last fortnight with regard to the acceptability criteria outlined in the process for new DSs at https://wiki.edgexfoundry.org/x/_QHiAQ and it was agreed in this week's working group meeting that the service be accepted.

Please approve this request with a vote of +1.

Regards,
Iain

Updated Event: EdgeX: UI Project Group Meeting #cal-invite

EdgeX-TSC@lists.edgexfoundry.org Calendar <EdgeX-TSC@...>
 

EdgeX: UI Project Group Meeting

When:
Tuesday, 7 January 2020
10:00am to 11:00am
(UTC+08:00) Asia/Chongqing
Repeats: Every 2 weeks on Tuesday

Where:
https://zoom.us/j/974194461

Organizer: Jim White EdgeX-TSC@...

An RSVP is requested. Click here to RSVP

Description:
Join Zoom Meeting
https://zoom.us/j/974194461

One tap mobile
+16699006833,,974194461# US (San Jose)
+16465588656,,974194461# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 974 194 461
Find your local number: https://zoom.us/u/abscayLpz

EdgeX: UI Project Group Meeting - Wed, 12/18/2019 #cal-notice

EdgeX-TSC@lists.edgexfoundry.org Calendar <noreply@...>
 

EdgeX: UI Project Group Meeting

When:
Wednesday, 18 December 2019
10:00am to 11:00am
(GMT+08:00) Asia/Chongqing

Where:
https://zoom.us/j/974194461

Organizer:
EdgeX-TSC@...

Description:
Join Zoom Meeting
https://zoom.us/j/974194461

One tap mobile
+16699006833,,974194461# US (San Jose)
+16465588656,,974194461# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 974 194 461
Find your local number: https://zoom.us/u/abscayLpz

Upcoming Event: EdgeX: UI Project Group Meeting - Wed, 12/18/2019 10:00am-11:00am, Please RSVP #cal-reminder

EdgeX-TSC@lists.edgexfoundry.org Calendar <EdgeX-TSC@...>
 

Reminder: EdgeX: UI Project Group Meeting

When: Wednesday, 18 December 2019, 10:00am to 11:00am, (GMT+08:00) Asia/Chongqing

Where:https://zoom.us/j/974194461

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC@...

Description: Join Zoom Meeting
https://zoom.us/j/974194461

One tap mobile
+16699006833,,974194461# US (San Jose)
+16465588656,,974194461# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 974 194 461
Find your local number: https://zoom.us/u/abscayLpz

Re: Critical feedback requested on API design / Swagger docs by Dec 15

Trevor.Conn@...
 

See below for inline comments.

 

Trevor

 

From: EdgeX-TSC@... <EdgeX-TSC@...> On Behalf Of espy
Sent: Tuesday, December 17, 2019 1:45 PM
To: Jim White;
🐙 TSC
Subject: Re: [Edgex-tsc] Critical feedback requested on API design / Swagger docs by Dec 15

 

[EXTERNAL EMAIL]

On 12/9/19 12:45 PM, Jim White wrote:

All,

Trevor Conn has presented his Geneva API proposal to several working groups and introduced it at the F2F meeting.  He is asking for all WG leads and architects to have a look by December 15th.  If you do not provide any input or feedback, it is assumed you agree with what he has proposed.  Find his proposal (for the core and supporting services) here:  https://github.com/tsconn23/edgex-geneva-api

 

Remember, this API change will eventually be worked through the entire system.  In particular, it affects how we look at requests and responses and would be the "v2" of our APIs.

 

He has been requested to provide a level of effort and impact briefing to the TSC by Christmas (per our F2F meeting).  Thus the deadline for your feedback.

Here's my belated feedback on your API proposal Trevor.

Note - I only reviewed the Open API spec for Core Metadata, however I think many of my comments might apply to wider set of service endpoints.

Regards,
/tony

---

ADR feedback

** 3.) Support multiple requests at once **

Isn't this accomplished by modifying endpoints which support creation of objects to accept arrays of request bodies?

 

Yes. That’s what is in the definition.

 

** 6.) Each service should provide a "bulk" request endpoint **

If this endpoint is supposed to accept requests to any other endpoint, then it seems it's more of a batch endpoint vs. bulk. See: https://www.codementor.io/blog/batch-endpoints-6olbjay1hd

 

This is the one area of the design, I'm less comfortable with, especially given the current schedule. I'd like to see this part of the design fleshed out a little bit more, maybe with some examples (see the above article). I also think we could make this optional for Genava, as long as we design for it. If we do implement it for Geneva my vote would be to do so for a limited numbers of services and call it "experimental".

 

Note - it looks like this current design is closer to an approach used by PayPal than the approach used by Google for gdrive (again see the article above).

API (core-metadata.yaml) feedback

 

1) General 

  • DTO isn't really used in the OpenAPI spec, is there an equivalent term?

We’ve used DTO because we’re trying to convey that the goal of the specification for request/response types is transport agnostic.

 

  • Other than the BulkRequest/Response, and CorrelatedRequest/Response, very few, if any of the properties include descriptions

As I said in the Core Working Group and on several emails, I’m looking for comments on the overall approach. Descriptions can be filled in later. Hell, our current API suffers from a lack of descriptions.

 

  • openapi suggests that the top-level document is called openapi.json or openapi.yaml

If we take this suggestion we’d have a folder for each service. Each folder would then contain an openapi.yaml. I don’t have a strong preference here.

 

  • Some requests (e.g. AddAddressableRequest, AddDeviceReq) specify individual properties, whereas other requests (e.g. AddDeviceProfile) specify a full object (e.g. DeviceProfile). Why?

The DeviceProfile is an extremely complex type that has numerous nested types within it. I don’t think it would be practical to create request/response types for all of its components as that would imply individual “Add” requests in order to assemble the DeviceProfile. I don’t hear any opinion that the DeviceProfile shouldn’t continue to be created as a unit. Addressables and Devices on the other hand can be created with just a handful of properties. Devices can simply refer to addressables and services that already exist.

 

  • In many of the Update*Request objects (eg. UpdateAddressableReq, UpdateDeviceReq, …) both id and name are required. Why?

Because of the current API. On the whole we do not have a strategy about what to do regarding the fact that ID/Name serve the same purpose. Both are unique identifiers, which is unfortunate in my opinion. In lieu of any better ideas, I preserved the existing API signatures. This applies to other comments below.

 

  • Sometime id and name are used, and sometimes <obj>Id and <Obj>Name are used. We should ensure that consistent naming is used…
  • In some of the Update*Response objects (e.g. UpdateAdddessableResponse), id is denoted as required. I'm not sure what that means?

This indicates the Id property of the response must be populated. The caller can thus assume there will be a value in this property.

 

 

2) Schema

 

= AddAddressableResponse =

  • In PHX, you'd proposed generic responses for things which created objects. What happened to this? It would get rid of a huge amount of boilerplate both in the schema and paths sections, especially if used across services.
  • message: is this actually used for anything (applies to all response)?

We backed away from this in order to preserve semantic meaning, particularly if the transport is not HTTP/REST

 

= AddDeviceRequest =

  • operatingState - this a runtime state? I think only adminState can be defined when creating a new device

Currently the endpoint to add a device takes a core-contracts/Device model. That Device model has an OperatingState property which is why the above property exists. This means that currently, YES it can be set when adding a device. If that’s incorrect, I’m happy to remove from the new spec.

 

= AddDeviceServiceRequest =

  • addressableName - shouldn't this be Id?  ** See above w/r/t name vs ID. Right now, what’s the difference? **
  • adminState - why is it required? Shouldn't default just be ENABLED like for AddDevice? ** If there’s a default then the field is required to have a value, no? The type’s constructor could set this value. **
  • operatingState - same as w/AddDeviceReq

 

= CorrelatedRequest =

  • correlationId: If using REST, this should be the same as the header X-Correlation-Id
  • Doesn't this means it's duplicated in each response object? Why? ** Yes – because in a non-HTTP transport the correlation ID denotes the overall batch of requests. The request ID identifies each individual request. **
    • requestId: why isn't it required? ** I have updated this in master **
  • version: I'm not sure how version relates the the endpoint version? ** I’m going to let Michael Estrin answer this **
  • shouldn't this be defined in its own file and referenced from all of the other API docs ** Sure, if that’s possible. Do you have an example? **

 

= CorrelatedResponse =

  • description:
    • describes correlationId, not CorrelatedResponse
    • The responses can be returned as a batch or individually. How?
    • It doesn't matter as long as both of these properties are correctly set… which properties? ** Fine, I’ll reword the verbiage **
  • correlationId: same as above (also property name is a bit long)
  • version: same concern as above
  • statusCode: this should explicitly state this is an HTTP Status code. ** It may not be though **

 

=  Device =

  • Why does a Device have an addressableName and addressableId? ** See above. These are both unique identifiers that are ambiguous in our current API **

 

= BulkRequest = ** Tagging Michael Estrin for follow-up here **

  • As designed, how does this endpoint support calls to multiple endpoints as there's no path defined in the request object?  How does this differ then from our singular endpoints being re-factored to support arrays of request bodies?
  • content: the type string with format byte indicates that this field contains base64 encoded binary data. Was that intended?
  • dtoVersion: earlier 'version' is used for DTO versions. Also if DTO 'version' is part of CorrelatedRequest, why is it needed again here? Same comment about the response...
  • type: in our use case, this would either be application/cbor or application/json right or does this define a schema type (eg. AddAddressableRequest)?

 

= Command/CommandResponse =

  • As part of device profile simplification, I question whether these definitions are truly needed, especially the CommandResponses which should be the same across all device services and profiles. Maybe something for Iain to think about?
  •  
  •  

= ProfileProperty =

  • We've long wanted to get rid of UnitProperty and make it a string in DeviceResource… thus we could simplify DeviceResource and get rid of Units.

 

= UpdateAddressableRequest =

  • Shouldn't there be at least one other field required?

 

= UpdateDeviceRequest =

  • operatingState shouldn't be update-able
  • should profile and protocol props be update-able?

 

= UpdateDeviceServiceRequest =

  • remove operatingState
  •  
  •  

3) parameters

 

= limitParam =

  • Why is the max only 50? I imagine there may be many models with more than 50 instances?

** This indicates the # of results on a page. It is used in tandem with offsetParam which indicates the page. You don’t like 50? I can make it a 1000. Think about the # of results you’d want to see on a page in a browser. **

 

= correlatedRequestHeader =

  • Why isn't this in defined as a header? ** It is **
  •  
  •  

4) paths

 

= addressable =

  • I'm not sure how  CorrelationHeader is used for the endpoint? This endpoint can take an array of AddAddressable or UpdateAddressable requests. Why would a call to do either operation required? From your descriptions so far, I think this only makes sense if the bulk endpoint is called?
  •  

Addressable

A larger topic, why do all of our service objects require embedded Addressable objects, which are also stored in a separate table? We get service info from the registry or local configuration. What value does having a shared table provide?

 

Re: Critical feedback requested on API design / Swagger docs by Dec 15

espy
 

On 12/9/19 12:45 PM, Jim White wrote:

All,
Trevor Conn has presented his Geneva API proposal to several working groups and introduced it at the F2F meeting.  He is asking for all WG leads and architects to have a look by December 15th.  If you do not provide any input or feedback, it is assumed you agree with what he has proposed.  Find his proposal (for the core and supporting services) here:  https://github.com/tsconn23/edgex-geneva-api

Remember, this API change will eventually be worked through the entire system.  In particular, it affects how we look at requests and responses and would be the "v2" of our APIs.

He has been requested to provide a level of effort and impact briefing to the TSC by Christmas (per our F2F meeting).  Thus the deadline for your feedback.

Here's my belated feedback on your API proposal Trevor.

Note - I only reviewed the Open API spec for Core Metadata, however I think many of my comments might apply to wider set of service endpoints.

Regards,
/tony

---

ADR feedback

** 3.) Support multiple requests at once **

Isn't this accomplished by modifying endpoints which support creation of objects to accept arrays of request bodies?


** 6.) Each service should provide a "bulk" request endpoint **

If this endpoint is supposed to accept requests to any other endpoint, then it seems it's more of a batch endpoint vs. bulk. See: https://www.codementor.io/blog/batch-endpoints-6olbjay1hd


This is the one area of the design, I'm less comfortable with, especially given the current schedule. I'd like to see this part of the design fleshed out a little bit more, maybe with some examples (see the above article). I also think we could make this optional for Genava, as long as we design for it. If we do implement it for Geneva my vote would be to do so for a limited numbers of services and call it "experimental".


Note - it looks like this current design is closer to an approach used by PayPal than the approach used by Google for gdrive (again see the article above).

API (core-metadata.yaml) feedback


1) General 

  • DTO isn't really used in the OpenAPI spec, is there an equivalent term?

  • Other than the BulkRequest/Response, and CorrelatedRequest/Response, very few, if any of the properties include descriptions

  • openapi suggests that the top-level document is called openapi.json or openapi.yaml

  • Some requests (e.g. AddAddressableRequest, AddDeviceReq) specify individual properties, whereas other requests (e.g. AddDeviceProfile) specify a full object (e.g. DeviceProfile). Why?

  • In many of the Update*Request objects (eg. UpdateAddressableReq, UpdateDeviceReq, …) both id and name are required. Why?

  • Sometime id and name are used, and sometimes <obj>Id and <Obj>Name are used. We should ensure that consistent naming is used…

  • In some of the Update*Response objects (e.g. UpdateAdddessableResponse), id is denoted as required. I'm not sure what that means?


2) Schema


= AddAddressableResponse =

  • In PHX, you'd proposed generic responses for things which created objects. What happened to this? It would get rid of a huge amount of boilerplate both in the schema and paths sections, especially if used across services.

  • message: is this actually used for anything (applies to all response)?

= AddDeviceRequest =

  • operatingState - this a runtime state? I think only adminState can be defined when creating a new device

= AddDeviceServiceRequest =

  • addressableName - shouldn't this be Id?

  • adminState - why is it required? Shouldn't default just be ENABLED like for AddDevice?

  • operatingState - same as w/AddDeviceReq


= CorrelatedRequest =

  • correlationId: If using REST, this should be the same as the header X-Correlation-Id

    • Doesn't this means it's duplicated in each response object? Why? 

    • requestId: why isn't it required?

  • version: I'm not sure how version relates the the endpoint version?

  • shouldn't this be defined in its own file and referenced from all of the other API docs


= CorrelatedResponse =

  • description:

    • describes correlationId, not CorrelatedResponse

    • The responses can be returned as a batch or individually. How?

    • It doesn't matter as long as both of these properties are correctly set… which properties?

  • correlationId: same as above (also property name is a bit long)

  • version: same concern as above

  • statusCode: this should explicitly state this is an HTTP Status code.


=  Device =

  • Why does a Device have an addressableName and addressableId?


= BulkRequest =

  • As designed, how does this endpoint support calls to multiple endpoints as there's no path defined in the request object?  How does this differ then from our singular endpoints being re-factored to support arrays of request bodies?

  • content: the type string with format byte indicates that this field contains base64 encoded binary data. Was that intended?

  • dtoVersion: earlier 'version' is used for DTO versions. Also if DTO 'version' is part of CorrelatedRequest, why is it needed again here? Same comment about the response...

  • type: in our use case, this would either be application/cbor or application/json right or does this define a schema type (eg. AddAddressableRequest)?


= Command/CommandResponse =

  • As part of device profile simplification, I question whether these definitions are truly needed, especially the CommandResponses which should be the same across all device services and profiles. Maybe something for Iain to think about?

= ProfileProperty =

  • We've long wanted to get rid of UnitProperty and make it a string in DeviceResource… thus we could simplify DeviceResource and get rid of Units.


= UpdateAddressableRequest =

  • Shouldn't there be at least one other field required?


= UpdateDeviceRequest =

  • operatingState shouldn't be update-able

  • should profile and protocol props be update-able?


= UpdateDeviceServiceRequest =

  • remove operatingState

3) parameters


= limitParam =

  • Why is the max only 50? I imagine there may be many models with more than 50 instances?


= correlatedRequestHeader =

  • Why isn't this in defined as a header?

4) paths


= addressable =

  • I'm not sure how  CorrelationHeader is used for the endpoint? This endpoint can take an array of AddAddressable or UpdateAddressable requests. Why would a call to do either operation required? From your descriptions so far, I think this only makes sense if the bulk endpoint is called?

Addressable

A larger topic, why do all of our service objects require embedded Addressable objects, which are also stored in a separate table? We get service info from the registry or local configuration. What value does having a shared table provide?


Re: Issue/project management proposal (architecture WG)

Jim White
 

Bryon - nice work on this document.
Regarding: Other open is whether this document should also discuss business process around pull request management.

I would say let's try to get this finalized and adopted separately from other process discussions.  If the community feels we need better process around pull request management, we can take that up as a separate issue.  

Jim White
CTO, IOTech
EdgeX Foundry co-founder & TSC Vice-chairman
On EdgeX Slack @ jpwhite
612-916-6693


On Mon, 16 Dec 2019 at 12:14, Bryon Nevis <bryon.nevis@...> wrote:
Posting this document for feedback from the Architects WG prior to bringing this to TSC officially.

As discussed in the Geneva F2F we are looking to get a better handle on project management using the currently available tools (i.e. GitHub).  I have attached a document that reverse-engineers what I perceive as the current business process around GitHub issue and project management features, based on my own biases and early reviews and discussion with DevOps, Security WG, and one architecture WG meeting.  The goal is to obtain agreement from the various working groups on the underlying meaning of the various fields/labels so that we can more effectively communicate and plan, and to then propose this for TSC-level adoption.

The current hot button issue in this document is what the "Milestone" field means and if it should be used at all. (I personally have gone back and forth.)  Other open is whether this document should also discuss business process around pull request management.

Please provide feedback to me or this mail list using the same subject.  If I have missed anyone who feels they should be listed in the author's list please let me know--I would like to give credit to everyone involved in defining our process.





Re: EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

Iain Anderson
 

+1



On 12/12/2019 21:53, Gregg, James R wrote:

TSC members,

Today in the EdgeX DevOps WG meeting, Lisa Rashidi-ranjbar introduced a proposal to implement a new image retention policy for our Docker artifacts managed on Nexus3.

 

This policy introduces both a new image tagging convention as well as a life cycle retention policy for the different repos where we manage our Docker images.

The goal of this proposal is to:

  • Make it easier to find images easier within the repositories
  • Reduce the overhead of storing / managing images
  • Establish a tagging convention on the images that will help us optimize validation and release processes


The full proposal is published to the EdgeX Foundry DevOps wiki - https://wiki.edgexfoundry.org/display/FA/DevOps+Working+Group?preview=/329486/37913075/EdgeX%20Nexus%20Retention%20Policy.pdf

The meeting minutes from the discussion within the working group meeting today is also published on the wiki - https://wiki.edgexfoundry.org/display/FA/DevOps+Working+Group?preview=/329486/37913073/EdgeX_DevOpsWG_Meeting_Minutes_WW50.pdf

It should be noted that per the working group discussion today, there was no objection to the proposed changes.

 

At this time and after your review of the referenced documents, please do consider your vote +1 / -1 for formal adoption of the change. 

 

Thank you

 

James Gregg

IOTG RBHE DevOps | EdgeX Foundry DevOps

Email: james.r.gregg@...

Tel: (480) 552-7965

 


Re: EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

Johanson, Michael
 

+1

 

From: EdgeX-TSC@... <EdgeX-TSC@...> On Behalf Of Trevor.Conn@...
Sent: Monday, December 16, 2019 8:50 AM
To: Corrion, Bradley W <bradley.w.corrion@...>; M.Estrin@...; Gregg, James R <james.r.gregg@...>
Cc: EdgeX-TSC@...
Subject: Re: [Edgex-tsc] EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

 

+1

 

From: EdgeX-TSC@... <EdgeX-TSC@...> On Behalf Of Corrion, Bradley W
Sent: Monday, December 16, 2019 9:46 AM
To: Estrin, Michael; Gregg, James R
Cc: EdgeX-TSC@...
Subject: Re: [Edgex-tsc] EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

 

[EXTERNAL EMAIL]

+1

 

From: <EdgeX-TSC@...> on behalf of Michael Estrin <m.estrin@...>
Date: Monday, December 16, 2019 at 11:02 AM
To: "Gregg, James R" <james.r.gregg@...>
Cc: "EdgeX-TSC@..." <EdgeX-TSC@...>
Subject: Re: [Edgex-tsc] EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

 

​+1


From: EdgeX-TSC@... <EdgeX-TSC@...> on behalf of Gregg, James R <james.r.gregg@...>
Sent: Thursday, December 12, 2019 3:53 PM
To: edgex-tsc@...
Subject: [Edgex-tsc] EdgeX DevOps Proposal - Nexus Life Cycle Retention Policy

 

[EXTERNAL EMAIL]

TSC members,

Today in the EdgeX DevOps WG meeting, Lisa Rashidi-ranjbar introduced a proposal to implement a new image retention policy for our Docker artifacts managed on Nexus3.

 

This policy introduces both a new image tagging convention as well as a life cycle retention policy for the different repos where we manage our Docker images.

The goal of this proposal is to:

  • Make it easier to find images easier within the repositories
  • Reduce the overhead of storing / managing images
  • Establish a tagging convention on the images that will help us optimize validation and release processes

The full proposal is published to the EdgeX Foundry DevOps wiki - https://wiki.edgexfoundry.org/display/FA/DevOps+Working+Group?preview=/329486/37913075/EdgeX%20Nexus%20Retention%20Policy.pdf

The meeting minutes from the discussion within the working group meeting today is also published on the wiki - https://wiki.edgexfoundry.org/display/FA/DevOps+Working+Group?preview=/329486/37913073/EdgeX_DevOpsWG_Meeting_Minutes_WW50.pdf

It should be noted that per the working group discussion today, there was no objection to the proposed changes.

 

At this time and after your review of the referenced documents, please do consider your vote +1 / -1 for formal adoption of the change. 

 

Thank you

 

James Gregg

IOTG RBHE DevOps | EdgeX Foundry DevOps

Email: james.r.gregg@...

Tel: (480) 552-7965

 

Re: Issue/project management proposal (architecture WG)

Iain Anderson
 



On 17/12/2019 00:23, espy wrote:

My proposal would be that a release label means the bug exists in the release(s) specified, and that a milestone means the bug/issue/feature has been committed for the release. As pointed out, if we close a bug that has multiple release labels, we may need to create a copy of the issue for the release(s) for which a fix has yet to land.


+1 on this. Both pieces of information are useful and having them both as labels would present readability issues.

My other thoughts on the document:

- It's probably worth highlighting the facility for having issue templates, which for example can automatically set labels on issue creation.

- I don't think the benefit of mandating an other-company reviewer is sufficient to require it.

- There's an inconsistent use of wontfix / willnotfix.

Regards,
Iain

Re: Issue/project management proposal (architecture WG)

espy
 

On 12/16/19 2:14 PM, Bryon Nevis wrote:

Posting this document for feedback from the Architects WG prior to bringing this to TSC officially.

As discussed in the Geneva F2F we are looking to get a better handle on project management using the currently available tools (i.e. GitHub).  I have attached a document that reverse-engineers what I perceive as the current business process around GitHub issue and project management features, based on my own biases and early reviews and discussion with DevOps, Security WG, and one architecture WG meeting.  The goal is to obtain agreement from the various working groups on the underlying meaning of the various fields/labels so that we can more effectively communicate and plan, and to then propose this for TSC-level adoption.

The current hot button issue in this document is what the "Milestone" field means and if it should be used at all. (I personally have gone back and forth.)  

In other bug trackers I've used, milestones usually represent some stage of a release with an associated date attached (eg. Geneva-Feature-Freeze, Geneva-Beta, ...), and when set, indicate a commitment to fixing the bug/issue by that date.

We've been somewhat overloading our usage of release labels. In some cases we've used it to indicate that a bug/issue exists in the specified release(s), and in some cases we've used it to indicate that the bug would be fixed in the indicated release. I don't think we can have it both ways.

My proposal would be that a release label means the bug exists in the release(s) specified, and that a milestone means the bug/issue/feature has been committed for the release. As pointed out, if we close a bug that has multiple release labels, we may need to create a copy of the issue for the release(s) for which a fix has yet to land.

Other open is whether this document should also discuss business process around pull request management.

My preference would be that PR process management be kept separate.

Regards,
/tony

Please provide feedback to me or this mail list using the same subject.  If I have missed anyone who feels they should be listed in the author's list please let me know--I would like to give credit to everyone involved in defining our process.