Topics

Config Mgmt Proposal V2

Trevor.Conn@...
 

Hi all -- I've incorporated Steve's feedback below into a V3 document. Please see attached. Let me know if there is any further comment. Today is my last official working day of 2018 so I'd like to get this tied off.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: Steve Osselton <steve@...>
Sent: Friday, December 21, 2018 2:49 AM
To: Conn, Trevor
Cc: edgex-tsc-core@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Config Mgmt Proposal V2
 

[EXTERNAL EMAIL]

Hi Trevor,

A couple of comments inline.

Cheers Steve.

On Thu, 20 Dec 2018 at 15:51, <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Steve – Replying to your questions below.

 

·         I think our assumption is that yes, the registry is specific to EdgeX since it is inside of the security boundary.

Perhaps in the reference docker deployment it is. But with us allowing alternate registry implementations, this may not always be the case,
so applying a scoping to all the EdgeX stuff, still makes sense to me. 

·         The “exf” prefix was brought up on last week’s Core WG call and was suggested because the LF apparently has a trademark on using this term as it applies to EdgeX. Tony also wanted something short, so there it is.

Yes but we use "core" in all sort of other contexts. IMHO we should try and use naming consistently (code, images. docs etc) for the sake of clarity and sanity.
Introducing another obscure namespace does not help IMHO. I hope no one is suggesting "efx" is better than "core" as it's one character less :)

·         “export” as high level category – I would suggest we let some of the discussions / direction in the Application WG mature a bit, but this could be where we put their configuration. I think the current export services should stay under efx, partly because I don’t see them moving out of the mono-repo and operating independently.

·         w/r/t your points on the “devices” section, this is totally your group’s call. We’ve decided that device services will bootstrap their own config, and they need a bucket in which to do that so we proposed “devices”. However you’d like to structure the configuration underneath is fine with me as this is independent of anything the config-seed will be doing.

Will discuss in the device services WG. 

 

Trevor

 

From: Steve Osselton [mailto:steve@...]
Sent: Sunday, December 16, 2018 4:03 AM
To: Conn, Trevor
Cc: edgex-tsc-core@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Config Mgmt Proposal V2

 

[EXTERNAL EMAIL]

Hi Trevor,

 

Good stuff. Some comments:

 

- Are we assuming that the registry is unique to EdgeX ? If not (i.e. potentially shared with other software

systems), then perhaps all settings should be scoped at the top level to "edgex".

 

- Why "efx' and not just "core"

 

- Think also need "export" as a high level category, as like devices in the future may be multiple instances.

 

- Presuming that everything under "devices" is a device instance name as may be deploying multiple instances

of the same device type.

 

- If have a typed category "devices" then naming things "device-xxx" under this seems like a device too far,

i.e can just be devices/mqtt-xxx etc.

 

- Might be worth considering allowing device instance names to hierarchical. Recently looked at a buildings

management system, where all devices were scoped based on location i.e. "building5/floor3/conf_room_1/heating controller".

Having devices in a flat structure is not going to scale and does not support deployment specific device hierarchy.

 

Cheers Steve.

 

On Sat, 15 Dec 2018 at 23:28, <Trevor.Conn@...> wrote:

Hi folks -- I've attached version 2 of the configuration proposal which has edits based on received comments to V1 and also our discussions in the Core Working Group meetings. In the section on versioning, I've tried to align with the proposal regarding releases and versioning being circulated by Jim White.

 

I look forward to any comments you may have.

 

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


 

--

Technical Director

IOTech Systems Ltd.



--
Technical Director
IOTech Systems Ltd.

Steve Osselton
 

Hi Trevor,

A couple of comments inline.

Cheers Steve.

On Thu, 20 Dec 2018 at 15:51, <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Steve – Replying to your questions below.

 

·         I think our assumption is that yes, the registry is specific to EdgeX since it is inside of the security boundary.

Perhaps in the reference docker deployment it is. But with us allowing alternate registry implementations, this may not always be the case,
so applying a scoping to all the EdgeX stuff, still makes sense to me. 

·         The “exf” prefix was brought up on last week’s Core WG call and was suggested because the LF apparently has a trademark on using this term as it applies to EdgeX. Tony also wanted something short, so there it is.

Yes but we use "core" in all sort of other contexts. IMHO we should try and use naming consistently (code, images. docs etc) for the sake of clarity and sanity.
Introducing another obscure namespace does not help IMHO. I hope no one is suggesting "efx" is better than "core" as it's one character less :)

·         “export” as high level category – I would suggest we let some of the discussions / direction in the Application WG mature a bit, but this could be where we put their configuration. I think the current export services should stay under efx, partly because I don’t see them moving out of the mono-repo and operating independently.

·         w/r/t your points on the “devices” section, this is totally your group’s call. We’ve decided that device services will bootstrap their own config, and they need a bucket in which to do that so we proposed “devices”. However you’d like to structure the configuration underneath is fine with me as this is independent of anything the config-seed will be doing.

Will discuss in the device services WG. 

 

Trevor

 

From: Steve Osselton [mailto:steve@...]
Sent: Sunday, December 16, 2018 4:03 AM
To: Conn, Trevor
Cc: edgex-tsc-core@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Config Mgmt Proposal V2

 

[EXTERNAL EMAIL]

Hi Trevor,

 

Good stuff. Some comments:

 

- Are we assuming that the registry is unique to EdgeX ? If not (i.e. potentially shared with other software

systems), then perhaps all settings should be scoped at the top level to "edgex".

 

- Why "efx' and not just "core"

 

- Think also need "export" as a high level category, as like devices in the future may be multiple instances.

 

- Presuming that everything under "devices" is a device instance name as may be deploying multiple instances

of the same device type.

 

- If have a typed category "devices" then naming things "device-xxx" under this seems like a device too far,

i.e can just be devices/mqtt-xxx etc.

 

- Might be worth considering allowing device instance names to hierarchical. Recently looked at a buildings

management system, where all devices were scoped based on location i.e. "building5/floor3/conf_room_1/heating controller".

Having devices in a flat structure is not going to scale and does not support deployment specific device hierarchy.

 

Cheers Steve.

 

On Sat, 15 Dec 2018 at 23:28, <Trevor.Conn@...> wrote:

Hi folks -- I've attached version 2 of the configuration proposal which has edits based on received comments to V1 and also our discussions in the Core Working Group meetings. In the section on versioning, I've tried to align with the proposal regarding releases and versioning being circulated by Jim White.

 

I look forward to any comments you may have.

 

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


 

--

Technical Director

IOTech Systems Ltd.



--
Technical Director
IOTech Systems Ltd.

Trevor.Conn@...
 

Dell Customer Communication

Hi Steve – Replying to your questions below.

 

·         I think our assumption is that yes, the registry is specific to EdgeX since it is inside of the security boundary.

·         The “exf” prefix was brought up on last week’s Core WG call and was suggested because the LF apparently has a trademark on using this term as it applies to EdgeX. Tony also wanted something short, so there it is.

·         “export” as high level category – I would suggest we let some of the discussions / direction in the Application WG mature a bit, but this could be where we put their configuration. I think the current export services should stay under efx, partly because I don’t see them moving out of the mono-repo and operating independently.

·         w/r/t your points on the “devices” section, this is totally your group’s call. We’ve decided that device services will bootstrap their own config, and they need a bucket in which to do that so we proposed “devices”. However you’d like to structure the configuration underneath is fine with me as this is independent of anything the config-seed will be doing.

 

Trevor

 

From: Steve Osselton [mailto:steve@...]
Sent: Sunday, December 16, 2018 4:03 AM
To: Conn, Trevor
Cc: edgex-tsc-core@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Config Mgmt Proposal V2

 

[EXTERNAL EMAIL]

Hi Trevor,

 

Good stuff. Some comments:

 

- Are we assuming that the registry is unique to EdgeX ? If not (i.e. potentially shared with other software

systems), then perhaps all settings should be scoped at the top level to "edgex".

 

- Why "efx' and not just "core"

 

- Think also need "export" as a high level category, as like devices in the future may be multiple instances.

 

- Presuming that everything under "devices" is a device instance name as may be deploying multiple instances

of the same device type.

 

- If have a typed category "devices" then naming things "device-xxx" under this seems like a device too far,

i.e can just be devices/mqtt-xxx etc.

 

- Might be worth considering allowing device instance names to hierarchical. Recently looked at a buildings

management system, where all devices were scoped based on location i.e. "building5/floor3/conf_room_1/heating controller".

Having devices in a flat structure is not going to scale and does not support deployment specific device hierarchy.

 

Cheers Steve.

 

On Sat, 15 Dec 2018 at 23:28, <Trevor.Conn@...> wrote:

Hi folks -- I've attached version 2 of the configuration proposal which has edits based on received comments to V1 and also our discussions in the Core Working Group meetings. In the section on versioning, I've tried to align with the proposal regarding releases and versioning being circulated by Jim White.

 

I look forward to any comments you may have.

 

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


 

--

Technical Director

IOTech Systems Ltd.

Steve Osselton
 

Hi Trevor,

Good stuff. Some comments:

- Are we assuming that the registry is unique to EdgeX ? If not (i.e. potentially shared with other software
systems), then perhaps all settings should be scoped at the top level to "edgex".

- Why "efx' and not just "core"

- Think also need "export" as a high level category, as like devices in the future may be multiple instances.

- Presuming that everything under "devices" is a device instance name as may be deploying multiple instances
of the same device type.

- If have a typed category "devices" then naming things "device-xxx" under this seems like a device too far,
i.e can just be devices/mqtt-xxx etc.

- Might be worth considering allowing device instance names to hierarchical. Recently looked at a buildings
management system, where all devices were scoped based on location i.e. "building5/floor3/conf_room_1/heating controller".
Having devices in a flat structure is not going to scale and does not support deployment specific device hierarchy.

Cheers Steve.

On Sat, 15 Dec 2018 at 23:28, <Trevor.Conn@...> wrote:

Hi folks -- I've attached version 2 of the configuration proposal which has edits based on received comments to V1 and also our discussions in the Core Working Group meetings. In the section on versioning, I've tried to align with the proposal regarding releases and versioning being circulated by Jim White.


I look forward to any comments you may have.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA



--
Technical Director
IOTech Systems Ltd.

Trevor.Conn@...
 

Hi folks -- I've attached version 2 of the configuration proposal which has edits based on received comments to V1 and also our discussions in the Core Working Group meetings. In the section on versioning, I've tried to align with the proposal regarding releases and versioning being circulated by Jim White.


I look forward to any comments you may have.


Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA