Date   
Re: Config Mgmt Proposal V2

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.

Re: Config Mgmt Proposal V2

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.

Re: Config Mgmt Proposal V2

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.

Re: 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.

Preliminary Doc on Moving to Go Modules

Trevor.Conn@...
 

Hi all -- I've attached a document that contains everything I can think of w/r/t accommodating Go Modules in our CI/CD pipeline. Moving to modules for dependency mgmt is a goal for the Edinburgh deliverable.


The intent is not to consider the attached doc as a final draft or plan. I'd like to use it as a basis for discussion during this week's upcoming DevOps call. From this we can work toward a plan so that we can have this done well in advance of mid-April.


Thanks.


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

Re: Preliminary Doc on Moving to Go Modules

Gregg, James R
 

Thanks Trevor.

I’ll add this to the agenda for this week.

 

~James R.Gregg

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Trevor.Conn@...
Sent: Monday, January 7, 2019 11:19 AM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules

 

Hi all -- I've attached a document that contains everything I can think of w/r/t accommodating Go Modules in our CI/CD pipeline. Moving to modules for dependency mgmt is a goal for the Edinburgh deliverable.

 

The intent is not to consider the attached doc as a final draft or plan. I'd like to use it as a basis for discussion during this week's upcoming DevOps call. From this we can work toward a plan so that we can have this done well in advance of mid-April.

 

Thanks.

 

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

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 01/17/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 17 January 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 01/24/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 24 January 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

Re: Preliminary Doc on Moving to Go Modules

Trevor.Conn@...
 

Hi all -- I'm going to piggy back on the thread below and loop in the Go email distro for more discussion about modules.

I've attached a V2 of the previous document that was sent. It includes two more bullet points w/r/t DevOps considerations, the final one being reference to a larger section about Go modules and how their adoption may affect the structure of our code repos as well as how we manage tags.


As I said below, I'm offering this proposal in the spirit of discussion. It represents the state of my thinking at the moment. There are some questions that I'd like to get feedback on from both the DevOps team and our Go experts. In addition to any feedback here, I imagine we'll be talking about this in the Working Group calls this week.


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


From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> on behalf of Gregg, James R <james.r.gregg@...>
Sent: Monday, January 7, 2019 12:21 PM
To: Conn, Trevor; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules
 

[EXTERNAL EMAIL]

Thanks Trevor.

I’ll add this to the agenda for this week.

 

~James R.Gregg

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Trevor.Conn@...
Sent: Monday, January 7, 2019 11:19 AM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules

 

Hi all -- I've attached a document that contains everything I can think of w/r/t accommodating Go Modules in our CI/CD pipeline. Moving to modules for dependency mgmt is a goal for the Edinburgh deliverable.

 

The intent is not to consider the attached doc as a final draft or plan. I'd like to use it as a basis for discussion during this week's upcoming DevOps call. From this we can work toward a plan so that we can have this done well in advance of mid-April.

 

Thanks.

 

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

Re: Preliminary Doc on Moving to Go Modules

jeremyphelps@...
 

Hi Everyone,
I think there is one main problem to consider when using go mod in a mono-repo.
- git tag collisions
    This could happen for example if when edgex-go goes from v1.0.0 to v2.0.0 if we also have pkg/contacts/v2 tagged at v2.0.0
I think that one possible way forward here is to use git submodules [1] for the internal deps.
ie; contacts v2 could live in it's own repo and be added to edgex-go as a submodule.  We could then direct go mod to look for the
appropriate contracts tag on a specific path inside of edgex-go; we can define this as we see fit.
This does potentially introduce some workflow complexity, which we should discuss this coming Thursday.
Thoughts?
Jeremy
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules

Re: Preliminary Doc on Moving to Go Modules

Gregg, James R
 

Jeremy,

I think in terms of the added workflow complexity, it would require additional overhead to the helpdesk / release engineer to create the repos where the submodules would reside. 

What else?

 

I know that ci-management has git submodules and it seems to work well as long as the developers remember to do a recursive pull to ensure that the submodule code is refreshed.

 

~ James Gregg

 

From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> On Behalf Of jeremyphelps@...
Sent: Monday, January 28, 2019 10:23 AM
To: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules

 

Hi Everyone,
I think there is one main problem to consider when using go mod in a mono-repo.
- git tag collisions
    This could happen for example if when edgex-go goes from v1.0.0 to v2.0.0 if we also have pkg/contacts/v2 tagged at v2.0.0
I think that one possible way forward here is to use git submodules [1] for the internal deps.
ie; contacts v2 could live in it's own repo and be added to edgex-go as a submodule.  We could then direct go mod to look for the
appropriate contracts tag on a specific path inside of edgex-go; we can define this as we see fit.
This does potentially introduce some workflow complexity, which we should discuss this coming Thursday.
Thoughts?
Jeremy
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules

Re: Preliminary Doc on Moving to Go Modules

Eric Ball
 

James,

In addition to the initial creation of the repo (which isn't a big deal) and devs needing to pull submodules, there's also the added step of having to update one repo (the one using the submodule) when the other one is updated. This is an extra step, and an easy one to forget, but it's certainly not a major source of complexity. Just something to keep in mind when weighing the options. Jeremy, please chime in if I forgot anything.

Eric Ball
Release Engineer
The Linux Foundation

On Wed, Jan 30, 2019 at 4:26 PM Gregg, James R <james.r.gregg@...> wrote:

Jeremy,

I think in terms of the added workflow complexity, it would require additional overhead to the helpdesk / release engineer to create the repos where the submodules would reside. 

What else?

 

I know that ci-management has git submodules and it seems to work well as long as the developers remember to do a recursive pull to ensure that the submodule code is refreshed.

 

~ James Gregg

 

From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> On Behalf Of jeremyphelps@...
Sent: Monday, January 28, 2019 10:23 AM
To: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules

 

Hi Everyone,
I think there is one main problem to consider when using go mod in a mono-repo.
- git tag collisions
    This could happen for example if when edgex-go goes from v1.0.0 to v2.0.0 if we also have pkg/contacts/v2 tagged at v2.0.0
I think that one possible way forward here is to use git submodules [1] for the internal deps.
ie; contacts v2 could live in it's own repo and be added to edgex-go as a submodule.  We could then direct go mod to look for the
appropriate contracts tag on a specific path inside of edgex-go; we can define this as we see fit.
This does potentially introduce some workflow complexity, which we should discuss this coming Thursday.
Thoughts?
Jeremy
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules

Re: Preliminary Doc on Moving to Go Modules

Gregg, James R
 

Thank you Eric
Is there additional overhead for setting team permissions that allow the update to the main repo?

Does LF manage GitHub via infrastructure as code?


On Jan 30, 2019, at 5:32 PM, Eric Ball <eball@...> wrote:

James,

In addition to the initial creation of the repo (which isn't a big deal) and devs needing to pull submodules, there's also the added step of having to update one repo (the one using the submodule) when the other one is updated. This is an extra step, and an easy one to forget, but it's certainly not a major source of complexity. Just something to keep in mind when weighing the options. Jeremy, please chime in if I forgot anything.

Eric Ball
Release Engineer
The Linux Foundation

On Wed, Jan 30, 2019 at 4:26 PM Gregg, James R <james.r.gregg@...> wrote:

Jeremy,

I think in terms of the added workflow complexity, it would require additional overhead to the helpdesk / release engineer to create the repos where the submodules would reside. 

What else?

 

I know that ci-management has git submodules and it seems to work well as long as the developers remember to do a recursive pull to ensure that the submodule code is refreshed.

 

~ James Gregg

 

From: EdgeX-TSC-DevOps@... <EdgeX-TSC-DevOps@...> On Behalf Of jeremyphelps@...
Sent: Monday, January 28, 2019 10:23 AM
To: EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Preliminary Doc on Moving to Go Modules

 

Hi Everyone,
I think there is one main problem to consider when using go mod in a mono-repo.
- git tag collisions
    This could happen for example if when edgex-go goes from v1.0.0 to v2.0.0 if we also have pkg/contacts/v2 tagged at v2.0.0
I think that one possible way forward here is to use git submodules [1] for the internal deps.
ie; contacts v2 could live in it's own repo and be added to edgex-go as a submodule.  We could then direct go mod to look for the
appropriate contracts tag on a specific path inside of edgex-go; we can define this as we see fit.
This does potentially introduce some workflow complexity, which we should discuss this coming Thursday.
Thoughts?
Jeremy
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 01/31/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 31 January 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 02/07/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 7 February 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 02/14/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 14 February 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

Proposal -- Release Versioning With Go Modules

Trevor.Conn@...
 

Hi all – Attached please find a proposal for handling our releases and versioning now that we’re well on our way to using Go modules. I suggest we give this some time for review in both the DevOps and Core Working Group calls tomorrow as time permits with other pre-existing agenda items.

 

This is only a proposal based on discussions we’ve had thus far with a view toward defining what our workflow will be for Edinburgh. Comments are welcome.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 02/21/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 21 February 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 02/28/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 28 February 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP

EdgeX TSC DevOps and QA/Test WG Meeting (Weekly) - Thu, 03/07/2019 7:00am-8:00am #cal-reminder

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

Reminder:
EdgeX TSC DevOps and QA/Test WG Meeting (Weekly)

When:
Thursday, 7 March 2019
7:00am to 8:00am
(GMT-08:00) America/Los Angeles

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

Organizer:
EdgeX-TSC-DevOps@...

Description:
EdgeX TSC DevOps and QA/Test WG Meeting. Meeting content posted to DevOps Wiki.
Meeting Lead: James Gregg, EdgeX DevOps WG Chair, james.r.gregg@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/967227826

Or iPhone one-tap :
    US: +16465588656,,967227826# or +16699006833,,967227826# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 967 227 826
    International numbers available: https://zoom.us/u/bmaYSxofb

An RSVP is requested. Click here to RSVP