Re: go repos concerns

James.White2@...
 

Fede, Drasko and Jeremy,

thanks all for the comments and review.  I will point you all to the fact that we did hash on this problem for some time in the working group meetings.  At the time, it was decided that each WG could feel free to implement as they see fit for this first implementation.  In the core WG we wanted libraries in different repo for the ability to share/modify them like we do in Java.  For others like in the Applications WG, you all wanted a single repo.


At that time, we all acknowledged that different approaches was going to create issues where duplication would occur in some cases (which we said was the responsibility of the maintainers to keep up with changes) and create complexity of many repo in other cases.


So while I follow and appreciate the discussion here, I fail to see any new evidence or arguments being introduced.  So are we all asking to open up this decision to new review?  And if we are reopening the discussion, are people wishing to change their original view point?


If we are just going to open this discussion to rehash the same issues and people are still holding to their same opinions, I am not sure of the value in doing so.  Instead, I'd like to have the teams make a little more progress in developing their respective Go services and then start to look at the issue again with more evidence of why we need to move in a particular direction.


Am I missing something?

Jim


From: edgex-golang-bounces@... <edgex-golang-bounces@...> on behalf of Jeremy Phelps <jphelps@...>
Sent: Monday, December 18, 2017 9:01 AM
To: Fede Claramonte
Cc: edgex-golang@...
Subject: Re: [Edgex-golang] go repos concerns
 
Hi Fede,
These are actually all really good points, I appreciate you bringing them up.  I agree that we need to discuss this as there are some cases where it could cause us some troubles.
For example...if the dependencies are vendored is there a way to pin to a specific version?

1) Each time a repo changes we all will need to update the vendor folder manually. I think it will be wearisome and error-prone.
    Not only that but how do we manage different versions under vendoring...there may be a case where the vendored code will be a release branch and not the tip of master for example.

2) Another problem is to know if a change in any module (e.g. core-domain-go) breaks some other module. We will need to manually compile all the dependent modules to make sure we will not break any other module.
    This is not a unique problem in this case I think.  This is just an issue with mico-services in general.  We can lessen the impact by strict adherence to sematic versioning and some smoke tests before we kick off blackbox-testing.

3) Previous point will be also influence how CI is implemented, it will need to launch several jobs after a change to test if it breaks some other module.
    I think this is what blackbox-testing would cover no?

On Mon, Dec 18, 2017 at 8:40 AM, Fede Claramonte <fclaramonte@...> wrote:
Hi all,

First of all I want to thank Dell for the initial go code for the core microservices. Good work.

I have been learning about the core Go code and I have some concerns about the layout of the code on different repositories.

We have several repos, each one with one different edgex module or lib. Each repo uses glide to vendor all dependencies, including the other edgex modules. So we have the same code copied over all the repositories in the vendor folder(e.g. core-domain-go, support-domain-go). My concerns:

1) Each time a repo changes we all will need to update the vendor folder manually. I think it will be wearisome and error-prone.

2) Another problem is to know if a change in any module (e.g. core-domain-go) breaks some other module. We will need to manually compile all the dependent modules to make sure we will not break any other module.

3) Previous point will be also influence how CI is implemented, it will need to launch several jobs after a change to test if it breaks some other module.

On the other hand we have the layout Drasko set up for export services. It contains all the needed code to compile several microservices and it is trivial to know when any change breaks some other module in the repo.

I would propose to use something similar to what Drasko did, i.e. having all/most of the edgex Go code in only one repo as follows:

edgex-go
├── cmd                 // The main file for each microservice in each folder
│   ├── core-data
│   ├── core-metadata
│   ├── export-client
│   ├── export-distro
│   └── support-logging
├── core                // core-domain-go
│   ├── clients         // core-clients-go
│   ├── data            // core-data-go
│   └── metadata        // core-metadata-go
├── device              // Device helplers
│   └── virtual         // device virtual
├── dockerfiles
├── export // The export repository
│ ├── client
│   └── distro
└── support             // support-domain-go
    └── logging

With this layout it will be easier to work with the code, all in only one repo. After changing something in edgex-go/core/XXX.go you just need to build and run the tests locally to know if the change breaks something. This is also a lot easier for CI, as there is no dependencies between different repos.

Opinions?

Fede

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

Join EdgeX-GoLang@lists.edgexfoundry.org to automatically receive all group messages.