Date   
Re: go service dependencies

Jeremy Phelps
 

Yes, we can spec a `version` parameter in glide.yaml
```
# The version can be a branch, tag, commit id, or a semantic version
# constraint parsable by https://github.com/Masterminds/semver
version: 1.0.0
```


On Wed, Jul 18, 2018 at 3:05 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

Have you seen an example/proposal for how this would be done?

 

I can add to our agenda under new business but we may not get to it this week as we have a pretty full list already.

 

Trevor

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Wednesday, July 18, 2018 3:02 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: go service dependencies

 

We currently manage go deps with glide.  Though we have discussed moving off of it I don't think we are currently ready.  As such, we need to make sure when we are pulling internal deps that we pull them from the correct branch since we now have california.

 

Example:

security-api-gateway pulls in edgex-go as a dep.

The glide.yaml for california branch (of security-api-gateway) should pull in the california branch of edgex-go.

 

This would be a good discussion point for the Core-WG meeting this week to look at if we should do this (if it is really an issue) for sure and some other finer points.

 

Jeremy


Re: go service dependencies

James.White2@...
 

Recommend this as a topic for DevOps meeting first; then loop in Core or other WG as necessary once an idea/plan is in place.

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Wednesday, July 18, 2018 3:08 PM
To: Conn, Trevor
Cc: edgex-tsc-devops@...; White2, James
Subject: Re: go service dependencies

 

Yes, we can spec a `version` parameter in glide.yaml

```

# The version can be a branch, tag, commit id, or a semantic version

 

# constraint parsable by https://github.com/Masterminds/semver

 

version: 1.0.0

```

 

 

On Wed, Jul 18, 2018 at 3:05 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

Have you seen an example/proposal for how this would be done?

 

I can add to our agenda under new business but we may not get to it this week as we have a pretty full list already.

 

Trevor

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Wednesday, July 18, 2018 3:02 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: go service dependencies

 

We currently manage go deps with glide.  Though we have discussed moving off of it I don't think we are currently ready.  As such, we need to make sure when we are pulling internal deps that we pull them from the correct branch since we now have california.

 

Example:

security-api-gateway pulls in edgex-go as a dep.

The glide.yaml for california branch (of security-api-gateway) should pull in the california branch of edgex-go.

 

This would be a good discussion point for the Core-WG meeting this week to look at if we should do this (if it is really an issue) for sure and some other finer points.

 

Jeremy

 

EdgeX CI systems update

Jeremy Phelps
 

Systems affected:

When:
July 24, 2018 from 10:00-11:00 AM Central Time

Why:
There are critical security updates to apply

Time:
Systems will be affected for approximately 1 hour and 15 minutes starting at 9:45 AM Central Time.  I will update when systems are online and operational again.

Re: [Edgex-tsc] EdgeX CI systems update

Jeremy Phelps
 

This maintenance is starting now.

On Mon, Jul 23, 2018 at 2:44 PM, Jeremy Phelps <jphelps@...> wrote:
Systems affected:

When:
July 24, 2018 from 10:00-11:00 AM Central Time

Why:
There are critical security updates to apply

Time:
Systems will be affected for approximately 1 hour and 15 minutes starting at 9:45 AM Central Time.  I will update when systems are online and operational again.


Re: [Edgex-tsc] EdgeX CI systems update

Jeremy Phelps
 

This maintenance has been completed and systems are back online.

On Tue, Jul 24, 2018 at 9:51 AM, Jeremy Phelps <jphelps@...> wrote:
This maintenance is starting now.

On Mon, Jul 23, 2018 at 2:44 PM, Jeremy Phelps <jphelps@...> wrote:
Systems affected:

When:
July 24, 2018 from 10:00-11:00 AM Central Time

Why:
There are critical security updates to apply

Time:
Systems will be affected for approximately 1 hour and 15 minutes starting at 9:45 AM Central Time.  I will update when systems are online and operational again.



Canceling DevOps WG Meeting Aug 6th

Jeremy Phelps
 

Hi All,
Do to unexpected circumstances I will be canceling today's scheduled DevOps WG Meeting.  If you have any pressing concerns please ping me on the devops mailing list and/or the chat and I will address them on Aug 7th.
Jeremy

System Migration

Jeremy Phelps
 

EdgeX Confluence (wiki.edgexfoundry.org) will be unavailable today from 7pm-8pm PST for
a migration.
I will update when it is operational again.
Jeremy

Re: [Edgex-tsc] System Migration

Jeremy Phelps
 

wiki.edgexfoundry.org is live again

On Tue, Sep 11, 2018 at 4:04 PM, Jeremy Phelps <jphelps@...> wrote:
EdgeX Confluence (wiki.edgexfoundry.org) will be unavailable today from 7pm-8pm PST for
a migration.
I will update when it is operational again.
Jeremy


EdgeX nexus system down

Jeremy Phelps
 

Hi All,
We are aware the nexus.edgexfoundry.org is down and our SA team are currently working to correct it.  Will update when it is available again.
Jeremy

Re: EdgeX nexus system down

Jeremy Phelps
 

All,
nexus.edgexfoundry.org is operational again.  Apologies for the delay.
Jeremy

On Wed, Sep 12, 2018 at 11:29 AM, Jeremy Phelps <jphelps@...> wrote:
Hi All,
We are aware the nexus.edgexfoundry.org is down and our SA team are currently working to correct it.  Will update when it is available again.
Jeremy


Upcoming CI System Downtime

Jeremy Phelps
 

Doodle poll to set up DevOps screenshare

Jeremy Phelps
 

Hi Folks,
I'll be doing a walk-through of how to interact with EdgeX CI systems.  Please fill in your meeting preference time on this doodle poll https://doodle.com/poll/n3npz6fvwk7tp273.
Specifically the focus will be on how you can create jenkins jobs and test jobs out on the Jenkins sandbox..  I will also touch on how Nexus works, and how we manage images with packer/ansible.

If you would like to follow along you can get a head start by doing the following:
1) pip install jenkins-job-builder (please save yourself trouble and use a virtualenv)
3) Read through https://lf-releng-docs.readthedocs.io/en/latest/ and note some questions to ask.

Thanks, I'm looking forward to this.
Jeremy

Re: [Edgex-tsc] Doodle poll to set up DevOps screenshare

Brett Preston
 

Please provide availability by EOD today. We are looking to have this meeting this week - Thanks!


On Mon, Oct 8, 2018 at 11:34 AM Jeremy Phelps <jphelps@...> wrote:
Hi Folks,
I'll be doing a walk-through of how to interact with EdgeX CI systems.  Please fill in your meeting preference time on this doodle poll https://doodle.com/poll/n3npz6fvwk7tp273.
Specifically the focus will be on how you can create jenkins jobs and test jobs out on the Jenkins sandbox..  I will also touch on how Nexus works, and how we manage images with packer/ansible.

If you would like to follow along you can get a head start by doing the following:
1) pip install jenkins-job-builder (please save yourself trouble and use a virtualenv)
3) Read through https://lf-releng-docs.readthedocs.io/en/latest/ and note some questions to ask.

Thanks, I'm looking forward to this.
Jeremy



--
Brett Preston
Sr. Program Manager
The Linux Foundation
+1 (971) 303-9030

EdgeX Systems Maintenance

Jeremy Phelps
 

Systems Affected:
jenkins.edgexfoundry.org
jenkins.edgexfoundry.org/sandbox
nexus.edgexfoundry.org
nexus3.edgexfoundry.org
wiki.edgexfoundry.org
chat.edgexfoundry.org

When:
Thursday Oct. 25th 2018 at 6:00PM UTC

Why:
OS updates

Time Required:
Maintenance is expected to last up to 2 hours.

LTS/STS strawman v2

James.White2@...
 

All,

Thanks for the input/feedback on the Long Term Support policy strawman at this week’s Devops Working Group call.  I have an updated version of the policy @ https://wiki.edgexfoundry.org/download/attachments/329486/LTS-draft-v2.pdf

 

Let’s discuss at the next DevOps/TestQA meeting.

 

Regards,

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

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@...

 

Config Mgmt Proposal V2

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

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.