Date   
Re: Delhi release version

James.White2@...
 

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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 Jeremy Phelps <jphelps@...>
Sent: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

Re: Delhi release version

Jeremy Phelps
 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.


On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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


From: EdgeX-TSC-DevOps@lists.edgexfoundry.org <EdgeX-TSC-DevOps@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 


Re: Delhi release version

James.White2@...
 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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 Jeremy Phelps <jphelps@...>
Sent: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 

Re: Delhi release version

Jeremy Phelps
 

We did discuss that, but then it felt wrong to me.  Let me draw up some processes to discuss during a newly formed DevOps meeting so we can hammer it out.

On Mon, Jul 9, 2018 at 9:27 PM, <Trevor.Conn@...> wrote:

Dell Customer Communication

But Jeremy, we discussed during the California release that going forward we would tag the master branch version as “master”. This tag would flow through to Docker Hub and would make our daily builds available via that tag. Couldn’t blackbox tests in the master branch then always target the master tag? Same for California and eventually Delhi?

 

Trevor

 

From: White2, James
Sent: Monday, July 9, 2018 9:25 PM
To: Jeremy Phelps
Cc: Conn, Trevor; EdgeX-TSC-DevOps@lists.edgexfoundry.org
Subject: RE: [Edgex-tsc-devops] Delhi release version

 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@lists.edgexfoundry.org
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@linuxfoundation.org]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@lists.edgexfoundry.org; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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


From: EdgeX-TSC-DevOps@lists.edgexfoundry.org <EdgeX-TSC-DevOps@lists.edgexfoundry.org> on behalf of Jeremy Phelps <jphelps@...>
Sent: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@lists.edgexfoundry.org; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 


Re: Delhi release version

Trevor.Conn@...
 

Dell Customer Communication

But Jeremy, we discussed during the California release that going forward we would tag the master branch version as “master”. This tag would flow through to Docker Hub and would make our daily builds available via that tag. Couldn’t blackbox tests in the master branch then always target the master tag? Same for California and eventually Delhi?

 

Trevor

 

From: White2, James
Sent: Monday, July 9, 2018 9:25 PM
To: Jeremy Phelps
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: RE: [Edgex-tsc-devops] Delhi release version

 

Ah – in that case… bump away.

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 9:23 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-TSC-DevOps@...
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

Building the artifacts with specified versions is different from git tagging.  The reason we want to bump the version on master before the release is for the daily staging jobs mostly.  We will be pointing blackbox tests at these, and to avoid confusion they should be different than our barcelona versions since they are already released.  Daily builds will of course overwrite but it's easier to reason about if we do bump.

 

 

On Mon, Jul 9, 2018 at 9:15 PM, <James.White2@...> wrote:

I am not sure we know what version number to give Delhi yet.  I’d like to think it might actually be 1.0, but too soon to label it at this time. 

Is it important to tag the branch now versus when we cut a release?  I don’t recall having to tag at the start of a release before.

 

Is there a reason we are tagging at the start of a release versus at the end?

 

From: Jeremy Phelps [mailto:jphelps@...]
Sent: Monday, July 09, 2018 4:22 PM
To: Conn, Trevor
Cc: EdgeX-TSC-DevOps@...; White2, James
Subject: Re: [Edgex-tsc-devops] Delhi release version

 

If we have the version for Delhi in the master branch already then we don't have that work to do after the cut.  The only work will be updating master again to the next release version.

 

On Mon, Jul 9, 2018 at 4:16 PM, <Trevor.Conn@...> wrote:

Hi Jeremy -- When you say "master" tag will hurt us, how do you mean? Wouldn't we just make a change to the desired version in the Delhi branch after the cut?

 

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 Jeremy Phelps <jphelps@...>
Sent: Monday, July 9, 2018 4:09 PM
To: edgex-tsc-devops@...; White2, James; Conn, Trevor
Subject: [Edgex-tsc-devops] Delhi release version

 

Hi I'd like to bump the version on master branch for the Delhi release.  I talked with Trevor a bit about just calling it "master" but that will hurt us come time to cut the branch.

Are we shooting for 0.7.0?

Jeremy

 

 

DevOps Meetings

Jeremy Phelps
 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

Some initial topics to discuss will be:
1) Developer Workflow (this will affect everyone)
2) Enhanced integration test
3) Release automation (to include branch cutting and versioning strategy)
4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.
5) Planning around supported docker-compose formats
6) Deprecation of java services

Once we agree on a time I will start a deck and share with the meeting invite.

Jeremy

Re: DevOps Meetings

James.White2@...
 

+1 – please invite me

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Tuesday, July 10, 2018 9:26 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] DevOps Meetings

 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

 

Some initial topics to discuss will be:

1) Developer Workflow (this will affect everyone)

2) Enhanced integration test

3) Release automation (to include branch cutting and versioning strategy)

4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.

5) Planning around supported docker-compose formats

6) Deprecation of java services

 

Once we agree on a time I will start a deck and share with the meeting invite.

 

Jeremy

Re: DevOps Meetings

Trevor.Conn@...
 

Dell Customer Communication

1-2PM Central time on Monday works for me!

 

Trevor

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Tuesday, July 10, 2018 9:26 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] DevOps Meetings

 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

 

Some initial topics to discuss will be:

1) Developer Workflow (this will affect everyone)

2) Enhanced integration test

3) Release automation (to include branch cutting and versioning strategy)

4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.

5) Planning around supported docker-compose formats

6) Deprecation of java services

 

Once we agree on a time I will start a deck and share with the meeting invite.

 

Jeremy

Re: DevOps Meetings

Michael Hall
 

Those time work for me, please add me to the invite.


On 07/10/2018 10:26 PM, Jeremy Phelps wrote:
We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

Some initial topics to discuss will be:
1) Developer Workflow (this will affect everyone)
2) Enhanced integration test
3) Release automation (to include branch cutting and versioning strategy)
4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.
5) Planning around supported docker-compose formats
6) Deprecation of java services

Once we agree on a time I will start a deck and share with the meeting invite.

Jeremy
-- 
Michael Hall
Contractor, The Linux Foundation

Emergency Jenkins Maintenance

Jeremy Phelps
 

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.
I appreciate your patience.
I will update when it is operational again.

Re: [Edgex-devel] Emergency Jenkins Maintenance

Jeremy Phelps
 

Build on Jenkins are executing again.

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:
htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.
I appreciate your patience.
I will update when it is operational again.


Re: [Edgex-devel] Emergency Jenkins Maintenance

Trevor.Conn@...
 

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Jeremy Phelps
 

Taking a look again.


On Wed, Jul 11, 2018, 20:01 <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Trevor.Conn@...
 

Dell Customer Communication

Running now. Thanks!

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 8:18 PM
To: Conn, Trevor
Cc: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Taking a look again.

 

On Wed, Jul 11, 2018, 20:01 <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: [Edgex-devel] Emergency Jenkins Maintenance

Jeremy Phelps
 

Ok I found the issue and builds are executing again.


On Wed, Jul 11, 2018, 20:39 <Trevor.Conn@...> wrote:

Dell Customer Communication

Running now. Thanks!

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 8:18 PM
To: Conn, Trevor
Cc: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Taking a look again.

 

On Wed, Jul 11, 2018, 20:01 <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi Jeremy – Looks like they might be stuck. There have been 10 in the queue for about an hour, no running agents.

 

Trevor

 

From: EdgeX-Devel@... [mailto:EdgeX-Devel@...] On Behalf Of Jeremy Phelps
Sent: Wednesday, July 11, 2018 6:57 PM
To: edgex-devel@...; edgex-tsc-devops@...
Subject: Re: [Edgex-devel] Emergency Jenkins Maintenance

 

Build on Jenkins are executing again.

 

On Wed, Jul 11, 2018 at 6:35 PM, Jeremy Phelps <jphelps@...> wrote:

htps://jenkins.edgexfoundry.org is down for a moment while I resolve a plugin incompatibility.

I appreciate your patience.

I will update when it is operational again.

 

 

Re: DevOps Meetings

James.White2@...
 

Jeremy,

 

We held our team meetings this week to discuss Delhi planning and EdgeX in general.  We agree that there is help to give and improvements to provide to DevOps.

Please also include Trevor and Brandon (copied) from our team on any DevOps meeting.

 

Also, we came up with some agenda items (possibly additions or echos to items you suggest below).  Here are our suggested topics for the re-started DevOps meeting.

 

•             We need test coverage / integration tests running well for all of EdgeX

•             We need to require tests are submitted for any new APIs/service updates as part of any PR

•             Test QA group needs to drive the infrastructure, but community needs to provide the appropriate tests

•             Black box tests need to run with each PR (but not necessarily halt merge of PR) and the black box tests need to run nightly with reports of failures/issues sent to subscribers email.

•             The EdgeX leadership and community need to be full participants to DevOps work.

•             We need all WG chairs with code responsibilities to be in DevOps meetings.  Everyone needs to be full participants and not leave Jeremy to do it all/solve it all.

•             We need DevOps backup/alternates from the community (we are looking internally at what we might be able to do/offer, but should solicit community as well)

•             Not against a release manager role, but what would they do?  How do they add value?

•             Recommend new PR/CI pipeline that looks like this:

 

From: White2, James
Sent: Tuesday, July 10, 2018 11:04 PM
To: 'Jeremy Phelps'; edgex-tsc-devops@...
Subject: RE: [Edgex-tsc-devops] DevOps Meetings

 

+1 – please invite me

 

From: EdgeX-TSC-DevOps@... [mailto:EdgeX-TSC-DevOps@...] On Behalf Of Jeremy Phelps
Sent: Tuesday, July 10, 2018 9:26 PM
To: edgex-tsc-devops@...
Subject: [Edgex-tsc-devops] DevOps Meetings

 

We are in need to set up the DevOps meeting again in order to plan more appropriately.  I am proposing a meeting time of 1pm-2pm Central Time on Monday's but want to get feedback from those interested in attending.

 

Some initial topics to discuss will be:

1) Developer Workflow (this will affect everyone)

2) Enhanced integration test

3) Release automation (to include branch cutting and versioning strategy)

4) Long running Jenkins job that runs EdgeX in a distributed environment using HEAT templates.

5) Planning around supported docker-compose formats

6) Deprecation of java services

 

Once we agree on a time I will start a deck and share with the meeting invite.

 

Jeremy

GitHub outage

Jeremy Phelps
 

GitHub is experiencing an outtage which will affect EdgeX CI.  Will update when they are back online.

Re: GitHub outage

Jeremy Phelps
 

GitHub is operational and CI is functional.

On Mon, Jul 16, 2018 at 12:43 PM, Jeremy Phelps <jphelps@...> wrote:
GitHub is experiencing an outtage which will affect EdgeX CI.  Will update when they are back online.


go service dependencies

Jeremy Phelps
 

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

Trevor.Conn@...
 

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