Topics

Go Lang Mono Repo - clean up and some issue resolution for Tuesday next

James.White2@...
 

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

Trevor.Conn@...
 

I just want to offer some comments on Jim’s first point below.

 

Really, Consul as EdgeX uses it serves two distinct purposes – configuration and service discovery. Consul is only one platform that provides these capabilities. I believe we need to work on introducing the appropriate abstractions into the GoLang codebase to allow extensibility and support for a number of providers. From what I know about GoLang so far, an approach to this end might be something like:

 

1.)    Define interfaces in the EdgeX codebase for configuration and service discovery providers (perhaps in a /providers directory tree).

a.       Even local file access for configuration should be done through this interface if remote providers aren’t available / disabled.

2.)    Inject the interfaces into EdgeX services where appropriate for configuration / service discovery.

a.       As an aside, services should register themselves with the Service Discovery provider if it is up and enabled. We shouldn’t tell a remote provider where to find services based on a statically defined config file.

3.)    Utilize a library such as hashicorp/consul in our reference implementation

a.       Direct library references should be contained to the providers/consul package. Everywhere else in code should use the interfaces.

b.      Customer forks could then add their own sub-ordinate packages (like providers/spring) without touching the interfaces.

We would need to take some care in defining the interfaces so that our reference implementation doesn’t constrain the vocabulary and operations we utilize.

 

We should also look into whether or not there is a worthwhile DI container for Go as we don’t want factory instantiation code all over the place, like for example:

 

loggingClient = logger.NewClient(configuration.Applicationname, configuration.EnableRemoteLogging, logTarget)

 

There are several that I found but I haven’t explored their merits yet.

·         Facebookgo/Inject

·         Alice

·         DI

One thing I am unsure of is whether or not GoLang is philosophically opposed to a DI container as being some kind of global state. I think that as long as the registered classes are stateless and we have the discipline to pass instances into functions as parameters rather than obtaining them from the container directly within a function we should be good.

 

The issue of which queueing provider to use is another place where it would be useful to have appropriate abstractions in the codebase.

 

Trevor

 

From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of White2, James
Sent: Friday, March 2, 2018 6:12 PM
To: edgex-golang@...
Subject: [Edgex-golang] Go Lang Mono Repo - clean up and some issue resolution for Tuesday next

 

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

 

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

Fede Claramonte
 

Hi Jim,
some comments inlined.

On 03/03/18 01:11, James.White2@... wrote:

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

Why having different profiles in consul?. In which scenario will the same consul instance be serving more than one profile? I should only use one profile in consul. This will require some change in config-seed, that should have several profiles for each microservice but only set one of them to consul.

I would like to change the algorithm to something like this. It have a valid configuration in the code, and then try to update it from file, environment and consul. But it does not requires any file to run correctly. For production in docker, the only needed configuration should be the consul address and setting consulRequired to true, that can be made with environment variables.

  • Default configuration in go, like export services. // Valid for development in localhost.
  • Read configuration from file, if available. // Useful for customize development and production environments. Having two different configurations in git, default the development and docker
  • Read configuration from environment variables. Useful to configure docker images, no need to generate a custom image with a different configuration file.
  • Registering with consul and read configuration, if available.
  • Read other microservices address from consul, if available.
  • if consul not availabe and config.consulRequired {
    •     retry consul or exit
  • }

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

I don't find it really useful. It is starting in less than a second and most of the time will be spent connecting to other services. But I don't oppose to have it. 

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

I don't like it, it is just a gorutine printing a log. Viewing the log does not gives you any information if the microservice is running fine, the main gorutines could be blocked somewhere else. If you really need know if the microservice is working you can use consul (health status) or just test the ping API

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

I agree. Most api and code layout should be made as similar between them as possible.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

Drasko already added an explanation on how to install zmq in debian based distributions. I never found any problem following his instructions.

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

First question should be if it should be added to git. It seems that the recommendation is to have it in git and set the version of the dependencies in glide.lock.


Fede

Steve Osselton
 

Just a quick thought WRT to 0MQ (and any other library dependency), have we considered using a binary repository for the build library (Conan),
would remove the dependency of having it installed on a build system?

Cheers Steve.

On 3 March 2018 at 00:11, <James.White2@...> wrote:

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang


James.White2@...
 

Dell - Internal Use - Confidential

Hi Steve,

We are exploring all sorts of options, but have not considered using a build library.

My first preference is to have something that is at least compiled with the application (Java and Go libs that can be used with their language compilers).  A binary library is an option if we think something like 0MQ is the long term strategy and we really want to maintain our own repo of pre-built binaries.  But we’d still have to create those (for the various platforms) and have the repo hosted somewhere (LF?).  And then we’d have to incorporate that pull of those for developer, docker builds, etc.  Not sure that saves us a ton.   Or am I missing something?

jim

 

From: Steve Osselton [mailto:steve@...]
Sent: Monday, March 05, 2018 8:25 AM
To: White2, James <James_White2@...>
Cc: edgex-golang@...
Subject: Re: [Edgex-golang] Go Lang Mono Repo - clean up and some issue resolution for Tuesday next

 

Just a quick thought WRT to 0MQ (and any other library dependency), have we considered using a binary repository for the build library (Conan),

would remove the dependency of having it installed on a build system?

 

Cheers Steve.

 

On 3 March 2018 at 00:11, <James.White2@...> wrote:

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

 

James.White2@...
 

Dell - Internal Use - Confidential

Hi Fede,

As we’ll be discussion this tomorrow in the GO meeting, let me just address the one question you had…

 

Why having different profiles in consul?. In which scenario will the same consul instance be serving more than one profile? I should only use one profile in consul. This will require some change in config-seed, that should have several profiles for each microservice but only set one of them to consul.

The key scenarios are: a) running as a developer and working on one service – and not needing Consul to work and test various elements of my work  b) testing – unit and integration testing should allow for tests to run in complete isolation and it may be the case that some configuration needs to be in place to exercise a particular tests.  c) running in production but outside of docker – you may want a different non-docker profile for when the service is running non-containerized or containerized by a different container strategy (say Snappy for instance). 

 

We must continue to build EdgeX so that developers can work on a single micro service without having necessarily to bring down and develop the world (all the micro services).  We must also continue to build EdgeX with isolation and ultimate flexibility in mind.  We may not use Consul long term or other users might want to replace Consul.  We must consider the reason micro services are so important to the community – they provide for flexibility in the platform that allows the end using community to use what it likes and discard/replace what it doesn’t.

 

Jim

 

From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Fede Claramonte
Sent: Monday, March 05, 2018 7:54 AM
To: edgex-golang@...
Subject: Re: [Edgex-golang] Go Lang Mono Repo - clean up and some issue resolution for Tuesday next

 

Hi Jim,
some comments inlined.

On 03/03/18 01:11, James.White2@... wrote:

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi                                                   

Why having different profiles in consul?. In which scenario will the same consul instance be serving more than one profile? I should only use one profile in consul. This will require some change in config-seed, that should have several profiles for each microservice but only set one of them to consul.

I would like to change the algorithm to something like this. It have a valid configuration in the code, and then try to update it from file, environment and consul. But it does not requires any file to run correctly. For production in docker, the only needed configuration should be the consul address and setting consulRequired to true, that can be made with environment variables.

  • Default configuration in go, like export services. // Valid for development in localhost.
  • Read configuration from file, if available. // Useful for customize development and production environments. Having two different configurations in git, default the development and docker
  • Read configuration from environment variables. Useful to configure docker images, no need to generate a custom image with a different configuration file.
  • Registering with consul and read configuration, if available.
  • Read other microservices address from consul, if available.
  • if consul not availabe and config.consulRequired {
    •     retry consul or exit
  • }



2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

I don't find it really useful. It is starting in less than a second and most of the time will be spent connecting to other services. But I don't oppose to have it. 

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

I don't like it, it is just a gorutine printing a log. Viewing the log does not gives you any information if the microservice is running fine, the main gorutines could be blocked somewhere else. If you really need know if the microservice is working you can use consul (health status) or just test the ping API

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

I agree. Most api and code layout should be made as similar between them as possible.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

Drasko already added an explanation on how to install zmq in debian based distributions. I never found any problem following his instructions.

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

First question should be if it should be added to git. It seems that the recommendation is to have it in git and set the version of the dependencies in glide.lock.


Fede

Steve Osselton
 

Hi Jim,

Probably not worth the bother of the infrastructure set up for just 0MQ, might have made more sense if
had a lot of binary dependencies, but don't think we do.

Cheers Steve.

On 5 March 2018 at 21:26, <James.White2@...> wrote:

Dell - Internal Use - Confidential

Hi Steve,

We are exploring all sorts of options, but have not considered using a build library.

My first preference is to have something that is at least compiled with the application (Java and Go libs that can be used with their language compilers).  A binary library is an option if we think something like 0MQ is the long term strategy and we really want to maintain our own repo of pre-built binaries.  But we’d still have to create those (for the various platforms) and have the repo hosted somewhere (LF?).  And then we’d have to incorporate that pull of those for developer, docker builds, etc.  Not sure that saves us a ton.   Or am I missing something?

jim

 

From: Steve Osselton [mailto:steve@...]
Sent: Monday, March 05, 2018 8:25 AM
To: White2, James <James_White2@...>
Cc: edgex-golang@lists.edgexfoundry.org
Subject: Re: [Edgex-golang] Go Lang Mono Repo - clean up and some issue resolution for Tuesday next

 

Just a quick thought WRT to 0MQ (and any other library dependency), have we considered using a binary repository for the build library (Conan),

would remove the dependency of having it installed on a build system?

 

Cheers Steve.

 

On 3 March 2018 at 00:11, <James.White2@...> wrote:

All,

Good work this week getting the mono repo and associated builds up and running.  During this week’s Go Project meeting (Tuesday), I’d like to address a few issues I see now that we have a single repo.  Consul being the chief among them

1.       Consul integration:  we need the Go code to operate as closely to the way the Java side works.  It provided for the flexibility of Consul or no-Consul and Docker or no-Docker (and allows for other container strategy later).  Here is what needs to be in the Go micro services:

·         There are two configurations associated to the application (in our core, we have made those external to the artifact in a res folder; in export, the config is in a .go file – I am ok with either approach but I want one for dockerized and one for non-docker environments)

·         Both configurations should also be in config-seed so Consul is prepopulated with the dockerized and non-dockerized config.  I recommend the following profile names:

o   <app-name>;docker;go

o   <app-name>;go

·         A bootstrap profile property specifies which configuration profile to use.  By default containerized properties should be used (profile=docker;go) but it could be set to use non-dockerized (profile=go) [ this is important for things like development where you don’t want to run in a container and some properties have to be set differently]

·         A second bootstrap property should specify whether to even attempt to connect and user Consul or not.  By default, this is set to true (in Java, the property was consul.enabled=true or false).

·         On start, the following algorithm is used…

If (consul.enabled=true)

If (Consul is up and the micro service can get to it)

micro service should register with Consul and get its configuration from Consul the <app-name>; <profile property> configuration profile in Consule

fi

else  # Consul is not up or consul.enabled=false

if (profile=docker;go)

micro service should get its configuration from the res folder or .go file associated to the docker;go configuration profile

else

micro service should get its configuration from the res folder or .go file associated to the ;go configuration profile

fi

fi

2.       In the Java code, the service would report to the log how long it took to start up the service.  Any reason why we can’t do this in Go?  An example is done with Core services?

3.       In the Java code, a heartbeat provided a log entry with a timestamp so that if you are looking at or tailing the logs, you had a sense the service was still alive.  Any reason why we can’t or shouldn’t do this?

4.       The main.go in cmd is consistent for all the Go services.  After that, it differs.  Should we have a consistently named kick-off function/file name for the main.go to call?  This could really help developers follow the line from the cmd/ folder to the micro service folder.

5.       Installing 0MQ is not exactly a straightforward process.  Until we replace it or have an alternate, can we add a script to install 0MQ?  I have referenced one in core data.  We can then reference this from the edgex-go README

6.       Where possible we should make the README’s consistent.  Someone want to take a shot at the README template?  Or pick one from the existing

7.       Should glide.lock be in .gitignore?

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 


_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang