Date   
Re: Mono repo Makefile changes?

Drasko DRASKOVIC <drasko.draskovic@...>
 

Hi Jeremy,

On Thu, Mar 8, 2018 at 12:11 AM, Jeremy Phelps
<jphelps@...> wrote:
Drasko,
Are you talking about these logs?
https://jenkins.edgexfoundry.org/job/edgex-go-master-verify-go-arm/75/console
No, #24 is not merged, as it is blocked by the issue noted in the
comment: https://github.com/edgexfoundry/edgex-go/pull/24

Problems are coming from #28:
https://github.com/edgexfoundry/edgex-go/pull/28, and Jenkins logs are
here: https://jenkins.edgexfoundry.org/job/edgex-go-master-verify-go-arm/69/

So - CI failed as it was supposed to do, so this is at least good
news. Bad news is that this is all Java to me :).

BR,
Drasko

Re: Mono repo Makefile changes?

James.White2@...
 

Dell - Internal Use - Confidential

( minus all the individual email addresses to remove unnecessary emails for those not concerned)

It was I that merged, but per comments you had asked that it be merged Drasko. Sorry 'bout that, but I thought we were not letting ARM build fails hold up the merge on purpose as we are still getting that work completed. Am I mistaken here??

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko.draskovic@...]
Sent: Wednesday, March 07, 2018 5:15 PM
To: White2, James <James_White2@...>
Cc: steve@...; espy <espy@...>; Keith Steele <keith@...>; edgex-golang@...
Subject: Re: [Edgex-golang] Mono repo Makefile changes?

On Thu, Mar 8, 2018 at 12:00 AM, Drasko DRASKOVIC <drasko.draskovic@...> wrote:
No problem Jim,
really no need to apologize. I do take my part of responsibility for
reviewing positively this commit - but it looks good indeed. I still
do not understand why CI did not break on existing target `build` that
was slightly changed.

Can somebody with ARM machine on his disposal please open an issue and
paste the error logs?
Argh... I just saw that we merged a PR even though CI was clearly stating that ARM build is failing:
https://github.com/edgexfoundry/edgex-go/pull/28

you can see this by clicking on "View Details", bottom right next to merge message.

Here is the error log:
https://jenkins.edgexfoundry.org/job/edgex-go-master-verify-go-arm/69/console

BR,
Drasko

Re: Mono repo Makefile changes?

Drasko DRASKOVIC <drasko.draskovic@...>
 

On Thu, Mar 8, 2018 at 12:28 AM, <James.White2@...> wrote:
Dell - Internal Use - Confidential

( minus all the individual email addresses to remove unnecessary emails for those not concerned)

It was I that merged, but per comments you had asked that it be merged Drasko. Sorry 'bout that, but I thought we were not letting ARM build fails hold up the merge on purpose as we are still getting that work completed. Am I mistaken here??
I do not know :).

I would personally propose that we maybe at least before merging
failing ARM CI try to figure out if it is something that can be easily
fixed. And if we however merge something that breaks ARM (no pun
intended), then I do agree that special warning would be convenient
(either by shouting this as a comment on GitHub, or on ML, or
similar...).

I'm sure that Fede will fix this quickly tomorrow, looks like
something in Cavium build environment (some Java stuff) is masking the
problem (I can not figure out what Java/JNR ssh-agent has to do with
Go build that is failing).

BR,
Drasko

Re: Mono repo Makefile changes?

Jeremy Phelps
 

Ah I remember that now on another PR; I triggered a recheck and it went away.  One of those intermittent issues.

On Wed, Mar 7, 2018 at 5:38 PM, Drasko DRASKOVIC <drasko.draskovic@...> wrote:
On Thu, Mar 8, 2018 at 12:28 AM,  <James.White2@...> wrote:
> Dell - Internal Use - Confidential
>
> ( minus all the individual email addresses to remove unnecessary emails for those not concerned)
>
> It was I that merged, but per comments you had asked that it be merged Drasko.  Sorry 'bout that, but I thought we were not letting ARM build fails hold up the merge on purpose as we are still getting that work completed.  Am I mistaken here??
>

I do not know :).

I would personally propose that we maybe at least before merging
failing ARM CI try to figure out if it is something that can be easily
fixed. And if we however merge something that breaks ARM (no pun
intended), then I do agree that special warning would be convenient
(either by shouting this as a comment on GitHub, or on ML, or
similar...).

I'm sure that Fede will fix this quickly tomorrow, looks like
something in Cavium build environment (some Java stuff) is masking the
problem (I can not figure out what Java/JNR ssh-agent has to do with
Go build that is failing).

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

Re: Mono repo Makefile changes?

Drasko DRASKOVIC <drasko.draskovic@...>
 

On Thu, Mar 8, 2018 at 12:58 AM, Jeremy Phelps
<jphelps@...> wrote:
Ah I remember that now on another PR; I triggered a recheck and it went
away. One of those intermittent issues.
Hmm... why is are then Tony and Steve seeing ARM build failures?

Tony, Steve,
can you please open the issue and post the error logs.

BR,
Drasko

Re: Mono repo Makefile changes?

Fede Claramonte
 

Hi Tony,

I was not aware of people already using the makefile in its own scripts. My objective was to improve CI, without changing the CI scripts themself.

But yes, I should added some information about the semantic makefile changes in the commit message, at least or better sending a mail to this maillist.

Regards,
Fede

On 03/07/2018 03:39 PM, espy wrote:
Looks like after our meeting last night, a number of outstanding pull requests got merged (including mine; thanks Jim!).

That said, my snap build breaks in a different manner this morning due to a Makefile change.

I was building all of the services in the mono repo using the following commands:

make prepare
make build

This no longer works.  I traced the change to this PR:

https://github.com/edgexfoundry/edgex-go/pull/28

My snap is building now, as I changed my build to use:

make prepare
make build_microservices

The PR explains why the change was made, but doesn't mention that 'make build' no longer builds the microservices.

In the future, if we change Makefile semantics, an email to the list would be helpful, and I would also ask that the associated commit message offer a bit more context.  The associated commit with this change was simply:

"Add new target to compile all go code"

Also I would've thought we'd want to keep "build" as a target for building all of the code in the repo?  It looks like none of our make targets are using any kind of prequisites, which could've been used to ensure proper ordering of the build.  It appears we're relying on both go and make for our builds, and thus the semantics of how the build actually works are a bit blurry.

Finally, the current clean target only appears to clean $(MICROSERVICES), so this will need to be fixed.

Thoughts?

Regards,
/tony

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

Re: Mono repo Makefile changes?

Fede Claramonte
 

Lets clarify somethins about the commit and the reasons I did like that:
- We found that some go code was not used by any microservice, so not compile by 'make build' that we were using (only generate the microservices) [1]
- I wanted the CI to test all our code, not just the code used by the microservices. CI is not doing yet anything with the artifacts, so they are not much important to me in that moment.
- I modified the build target to build everything, but without generating any microservice. I added a new target to generate the microservices, so we can still be able to generate the microservices, but with a different target.
- This change has nothing to do with arm64, once we get ride of zmq we will be able to cross-compile
- Our CI board is suffering from some disk fails(/ mounted readonly), we are trying to fix them. That is the cause of all the CI build errors and not the code itself.

Fede

[1] https://github.com/edgexfoundry/edgex-go/commit/4bfbc45b7b1df89d35a3f32390c0e722a400ae74

On 03/08/2018 01:00 AM, Drasko DRASKOVIC wrote:
On Thu, Mar 8, 2018 at 12:58 AM, Jeremy Phelps
<jphelps@...> wrote:
Ah I remember that now on another PR; I triggered a recheck and it went
away. One of those intermittent issues.
Hmm... why is are then Tony and Steve seeing ARM build failures?

Tony, Steve,
can you please open the issue and post the error logs.

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

Re: Mono repo Makefile changes?

espy
 

On 3/7/18 5:28 PM, Drasko DRASKOVIC wrote:

On Wed, Mar 7, 2018 at 5:37 PM, espy <espy@...> wrote:
On 03/07/2018 11:19 AM, James.White2@... wrote:
*Dell - Internal Use - Confidential

*

All

We cannot – we will not!!! – expect developers to read through all the PRs
to be able to pull down and work with EdgeX and have a proper build. This
is not a way to run a project.

If the build breaks and it is a result of something you added – the
responsibility is on the developer that caused the break to put a new PR in
place to fix it or reverse it as quickly as possible.

If you have something you think needs review/comments then I think we need
to use branches and seek comments via this email list, Rocket Chat, etc.

IF there are extenuating circumstances for a change to something like a
Makefile or any other elements that we know will cause a break – we
absolutely need a heads up *_BEFORE_* it breaks. In fact, do so and get the
ok from the community before so that you do not interrupt the course of
business.

*Drasko*– what does it take to get a fix in place ASAP??
Just to be clear, I'm unblocked at the moment, however I do think it would
make sense for us to take a good look at the current Makefile approach and
re-factor if/where appropriate.
Draskow -

You kinda missed the two points I was making:

 - I wasn't blocked, so no immediate action was necessary; I was actually trying to defuse the thread... ;)-

 - We should review our current Makefile approach, and revise if/where appropriate. I for one, still question if we need a "build_microservices" target.  Let's discuss during the Core WG meeting.

 And my original point was that if we change how the build works, please at minimum, mention the details in a commit message body (ideally), or email (less ideal).  In this case, if we keep build_microservices as is, then we probably should update README.md with the details.

Also one other minor issue I ran into was that even though I had libzmq-dev and pkg-config installed on my machine (Ubuntu 16.04.x), I had to manually specify CGO_LDFLAGS/CGO_CPPFLAGS in my snapcraft.yaml in order to get core-data and export-distro to build properly.

Regards,
/tony



I would also like to add that I would expect that every developer is
capable of doing `git chechout <git_hash_that_works>` and build the
SW. If you can not do this, you are probably not a developer and you
should not be building the SW in the first place, but downloading and
using pre-compiled binaries or whatever.

There is not even tagged MVP on this repo, not to mention an official
release. With all the effort that developers, CI, reviewers and
maintainers do, there will be some very rear occasions where master
might be broken. Checking out previous version and rewinding Git HEAD
to a previous commit (working one) is trivial, and should not block a
developer.

As soon as code stabilizes we can tag a release candidate v1.0.0-rc1.0
and release the binaries.

BR,
Drasko

EdgeX in embbeded device

Joan Duran
 

Hello!


We are a very interested in use EdgeX in a ARM device with low resources (RAM should be 256MB and NAND Flash 512MB). Also we will manage few devices (usually less than 10).


In our first tests, we detected two main issues with the current implementation of EdgeX using Go:

  1. It's painful to crosscompile 0MQ, so for us use another option like nanomsg/mangos looks like a good option.
  2. We can't use MongoDB, as it use a minimum of 100MB of RAM, and just creating the database uses around 600MB.

So we are looking for a MongoDB alternative, and we tried those options:

  1. Tideot [1]. Is a Go documental database, which can be embedded. We discarded this option because also uses a huge amount of Flash.
  2. SQlite3 [2][3]. A very known SQL database. We discarded this option because we want to avoid to crosscompile
  3. Bolt [4]. Is an embedded Go key/value database. We modified some parts of core-metadata and it's working fine.

What do you think about using Bolt with device with low resources as alternative of MongoDB? Do you know another options?


Of course, if everything goes fine, we will commit this changes and help with other things.


Best regards,

Joan


[1] https://github.com/HouzuoGuo/tiedot

[2] https://www.sqlite.org/index.html

[3] https://github.com/mattn/go-sqlite3

[4] https://github.com/coreos/bbolt



Re: Mono repo Makefile changes?

Fede Claramonte
 

There is the same problem when compiling their dockers. The compilation flags are diferent in alpine.

On 03/08/2018 04:51 PM, Tony Espy wrote:
Also one other minor issue I ran into was that even though I had libzmq-dev and pkg-config installed on my machine (Ubuntu 16.04.x), I had to manually specify CGO_LDFLAGS/CGO_CPPFLAGS in my snapcraft.yaml in order to get core-data and export-distro to build properly.

Re: EdgeX in embbeded device

Steve Osselton
 

Hi Joan,

Am doing exactly the same work here (getting EdgeX go services running on an embedded 32 bit platform)
and have exactly the same issues. Would be great to see a more efficient (go) mongo alternative.

Cheers Steve.

On 8 March 2018 at 15:52, Joan Duran <jduran@...> wrote:

Hello!


We are a very interested in use EdgeX in a ARM device with low resources (RAM should be 256MB and NAND Flash 512MB). Also we will manage few devices (usually less than 10).


In our first tests, we detected two main issues with the current implementation of EdgeX using Go:

  1. It's painful to crosscompile 0MQ, so for us use another option like nanomsg/mangos looks like a good option.
  2. We can't use MongoDB, as it use a minimum of 100MB of RAM, and just creating the database uses around 600MB.

So we are looking for a MongoDB alternative, and we tried those options:

  1. Tideot [1]. Is a Go documental database, which can be embedded. We discarded this option because also uses a huge amount of Flash.
  2. SQlite3 [2][3]. A very known SQL database. We discarded this option because we want to avoid to crosscompile
  3. Bolt [4]. Is an embedded Go key/value database. We modified some parts of core-metadata and it's working fine.

What do you think about using Bolt with device with low resources as alternative of MongoDB? Do you know another options?


Of course, if everything goes fine, we will commit this changes and help with other things.


Best regards,

Joan


[1] https://github.com/HouzuoGuo/tiedot

[2] https://www.sqlite.org/index.html

[3] https://github.com/mattn/go-sqlite3

[4] https://github.com/coreos/bbolt




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




--
Technical Director
IOTech Systems Ltd.

Re: EdgeX in embbeded device

Drasko DRASKOVIC <drasko@...>
 

Hello Joan,
during our last TSC meeting Go enthusiasts promoted the idea of EdgeX
running on RPi-like targets. We believe that this can be possible now,
thanks to Go footprint.

We are also aware that we'll have to advance on points of ZMQ and DB.

On Thu, Mar 8, 2018 at 4:52 PM, Joan Duran <jduran@...> wrote:
Hello!


We are a very interested in use EdgeX in a ARM device with low resources
(RAM should be 256MB and NAND Flash 512MB). Also we will manage few devices
(usually less than 10).


In our first tests, we detected two main issues with the current
implementation of EdgeX using Go:

It's painful to crosscompile 0MQ, so for us use another option like
nanomsg/mangos looks like a good option.

Yes - this has been discussed on mailing lists and Go IG meetings. We
are currently evaluating:
- Nanomsg (mangos)
- GRPC
- NATS

All approaches have benefits and drawbacks. I expressed my personal
preferences, you can find the thread in the ML archives.

We can't use MongoDB, as it use a minimum of 100MB of RAM, and just creating
the database uses around 600MB.
Depends. MongDB can be very small, and we need to see where data size
comes from.


So we are looking for a MongoDB alternative, and we tried those options:

Tideot [1]. Is a Go documental database, which can be embedded. We discarded
this option because also uses a huge amount of Flash.
SQlite3 [2][3]. A very known SQL database. We discarded this option because
we want to avoid to crosscompile
Bolt [4]. Is an embedded Go key/value database. We modified some parts of
core-metadata and it's working fine.

What do you think about using Bolt with device with low resources as
alternative of MongoDB? Do you know another options?

BoltDB is not an alternative to classical DB - it is in-RAM key-value
storage. It is industry-class product, but can not fully replace
SQL/NoSQL DBs.
Additionally, to avoid same class of CGO and cross-compilation
problems related to ZMQ, I would personally look into BadgerDB:
https://blog.dgraph.io/post/badger/, which is pure Go implementation
from dgraph team.

I would advise first analyzing the solution (how DB is used today in
EdgeX), and then proposing replacement. Bolt/Badger can be good for
PoC, however I expect that you will run in into the various problems:
- Size of available RAM
- Dropped and lost messages
- No qerying
- etc...

In this case I would personally lean towards SQL DB, probably start
with LightSQL, but code defensively and generically so that the same
code can tomorrow use Postgres or CockroachDB. This can be achieved
via gorm (https://github.com/jinzhu/gorm) as an abstraction layer.

Overall, my suggestions would be following:
- Actively participate in the community and join Go group meetings
- Investigate `nanomsg` vs `gRPC` vs `NATS` problem and give your
inputs to the community
- Once community reach this consensus and does the changes go to the
next step: storage
- Design (on the architectural level) abstraction layer around DB
storage, so that we can have detachable and replaceable DBs (i.e. stay
DB agnostic as much as possible - gorm is one of the ideas in this
direction)
- Implement Bolt/Badger PoC
- Implement gorm-based PoC


Of course, if everything goes fine, we will commit this changes and help
with other things.
Of course, I will not be helping unless I see your work incrementally
develop in a public repo under Apache-2.0 license. Throwing at us a
huge lump of code changes at one point out of nowhere is probably not
a good idea.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: Mono repo Makefile changes?

espy
 

On 3/8/18 11:00 AM, Fede Claramonte wrote:

There is the same problem when compiling their dockers. The compilation flags are diferent in alpine.
Is it possible to statically link libzmq when using cgo?

I actually build libzmq and include it in my snap directly, so I don't have to worry about dependencies like this.

/t



On 03/08/2018 04:51 PM, Tony Espy wrote:
Also one other minor issue I ran into was that even though I had libzmq-dev and pkg-config installed on my machine (Ubuntu 16.04.x), I had to manually specify CGO_LDFLAGS/CGO_CPPFLAGS in my snapcraft.yaml in order to get core-data and export-distro to build properly.
_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Extra merge commits & commit messages...

espy
 

A couple of suggestions about our git workflow, after poking around with git log...

1) Since we're using the github flow to merge our PRs, there are a lot of merge commits, however I'm also seeing quite a few merge commits that look like this:

Merge branch 'master' into <feature branch>

This happens when a feature branch sits around for awhile, and then has to be re-merged with HEAD. Now, I know it's easy to filter merge commits using 'git log --no-merges', but it's also easy to rebase your feature branch before pushing, or using 'git stash; git pull; git stash apply' to perform a similar workflow. Both techniques get rid of these merge commits, making our git history much cleaner.

2) Please make sure you follow our commit style guide!  There are bunch of commits that landed recently that are one long line of description.  The commit summary should be no more than 50 chars, and then feel free to write more detail in the message body.  'git log --oneline' makes these obvious.

Regards,
/tony

Re: Extra merge commits & commit messages...

Drasko DRASKOVIC <drasko.draskovic@...>
 

I think we're missing something like this:
https://github.com/mainflux/mainflux/blob/master/.github/CONTRIBUTING.md

If somebody (Tony?) can craft a CONTRIBUTING.md doc, that would be great, IMHO.

Also, issue template in .github would be good idea:
https://github.com/mainflux/mainflux/blob/master/.github/ISSUE_TEMPLATE.md

BR,
Drasko

On Thu, Mar 8, 2018 at 11:38 PM, Tony Espy <espy@...> wrote:
A couple of suggestions about our git workflow, after poking around with git
log...

1) Since we're using the github flow to merge our PRs, there are a lot of
merge commits, however I'm also seeing quite a few merge commits that look
like this:

Merge branch 'master' into <feature branch>

This happens when a feature branch sits around for awhile, and then has to
be re-merged with HEAD. Now, I know it's easy to filter merge commits using
'git log --no-merges', but it's also easy to rebase your feature branch
before pushing, or using 'git stash; git pull; git stash apply' to perform a
similar workflow. Both techniques get rid of these merge commits, making our
git history much cleaner.

2) Please make sure you follow our commit style guide! There are bunch of
commits that landed recently that are one long line of description. The
commit summary should be no more than 50 chars, and then feel free to write
more detail in the message body. 'git log --oneline' makes these obvious.

Regards,
/tony




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

Re: Extra merge commits & commit messages...

espy
 

On 3/8/18 5:43 PM, Drasko DRASKOVIC wrote:

I think we're missing something like this:
https://github.com/mainflux/mainflux/blob/master/.github/CONTRIBUTING.md

If somebody (Tony?) can craft a CONTRIBUTING.md doc, that would be great, IMHO.
Well as mentioned earlier, Andy did a great job writing up our code contribution guidelines on the wiki, but that said, I'm not opposed to a file in the repo either:

https://wiki.edgexfoundry.org/display/FA/Committing+Code+Guidelines

That said, maybe we just add a Contributing.md that points to our wiki page?

Regards,
/tony







Also, issue template in .github would be good idea:
https://github.com/mainflux/mainflux/blob/master/.github/ISSUE_TEMPLATE.md

BR,
Drasko

On Thu, Mar 8, 2018 at 11:38 PM, Tony Espy <espy@...> wrote:
A couple of suggestions about our git workflow, after poking around with git
log...

1) Since we're using the github flow to merge our PRs, there are a lot of
merge commits, however I'm also seeing quite a few merge commits that look
like this:

Merge branch 'master' into <feature branch>

This happens when a feature branch sits around for awhile, and then has to
be re-merged with HEAD. Now, I know it's easy to filter merge commits using
'git log --no-merges', but it's also easy to rebase your feature branch
before pushing, or using 'git stash; git pull; git stash apply' to perform a
similar workflow. Both techniques get rid of these merge commits, making our
git history much cleaner.

2) Please make sure you follow our commit style guide!  There are bunch of
commits that landed recently that are one long line of description.  The
commit summary should be no more than 50 chars, and then feel free to write
more detail in the message body.  'git log --oneline' makes these obvious.

Regards,
/tony




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

Re: Extra merge commits & commit messages...

James.White2@...
 

Dell - Internal Use - Confidential

Thanks Drasko. I like this.

I also just sent a note to Tony in that I think we need a video or tutorial that helps new developers to our community - a place to go to learn about the dos and don'ts of working in our community and with GitHub, etc.
I will admit, that I have a lot to learn in this area as well, and I suspect that while I am not the brightest bulb on the Christmas tree, if I am questioning and not sure about some of this, others are also. So we need to offer some education - and the more (video, .md doc, etc.) the better.

I will volunteer to help put some of this together if the experts can help me with the content.
Jim

-----Original Message-----
From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Drasko DRASKOVIC
Sent: Thursday, March 08, 2018 4:44 PM
To: Tony Espy <espy@...>
Cc: edgex-golang@...
Subject: Re: [Edgex-golang] Extra merge commits & commit messages...

I think we're missing something like this:
https://github.com/mainflux/mainflux/blob/master/.github/CONTRIBUTING.md

If somebody (Tony?) can craft a CONTRIBUTING.md doc, that would be great, IMHO.

Also, issue template in .github would be good idea:
https://github.com/mainflux/mainflux/blob/master/.github/ISSUE_TEMPLATE.md

BR,
Drasko

On Thu, Mar 8, 2018 at 11:38 PM, Tony Espy <espy@...> wrote:
A couple of suggestions about our git workflow, after poking around
with git log...

1) Since we're using the github flow to merge our PRs, there are a lot
of merge commits, however I'm also seeing quite a few merge commits
that look like this:

Merge branch 'master' into <feature branch>

This happens when a feature branch sits around for awhile, and then
has to be re-merged with HEAD. Now, I know it's easy to filter merge
commits using 'git log --no-merges', but it's also easy to rebase your
feature branch before pushing, or using 'git stash; git pull; git
stash apply' to perform a similar workflow. Both techniques get rid of
these merge commits, making our git history much cleaner.

2) Please make sure you follow our commit style guide! There are
bunch of commits that landed recently that are one long line of
description. The commit summary should be no more than 50 chars, and
then feel free to write more detail in the message body. 'git log --oneline' makes these obvious.

Regards,
/tony




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

Regarding Base Functionality in Core Services

Trevor.Conn@...
 

Hi folks -- With my most recent PR in the edgex-go repo I've started to consolidate some of the code repetition involved in bootstrapping the core services. For this particular PR, the target is the heartbeat functionality. As you can see, I moved the logic into a support/heartbeat package with is then called via one line in the main.go of each service.


heartbeat.Start(configuration.HeartBeatMsg, configuration.HeartBeatTime, loggingClient)


I don't necessarily think this is the best place for it, but it will do for now. We don't particularly have a good place in the package structure for common, base functionality required by all services in EdgeX. As Jim explained it to me, "support" is meant for optional services (like logging and notifications) so to me, the support package should be concerned solely with the implementation of these services (like "core" or "export"). So if we have functionality that cuts across all services, like a heartbeat or perhaps configuration, where should it go?


We should probably avoid overly broad terms like "common" or "libs". I don't know. "Service-base" or "aspects"? I'm concerned that "support" will become a dumping ground for miscellaneous stuff.


If anyone has any thoughts, let me know.


Also, please note that LoggingClient is now an interface. The heartbeat implementation receives this interface as a parameter and the unit test has its own mock implementation. I'll be emphasizing decoupling and unit testing as I make more changes.


Thanks,

Trevor


EdgeX: Move Go Project discussions under Core WG? [Poll]

Brett Preston
 

Members of the Go Project group,

Per discussions in the Core WG meeting on Thursday, March 9, a proposal was risen to end the Go Lang Project Group after the March 20 meeting, and address all Go related work/questions/issues in the Core Working Group moving forward.

Before any final decisions are made, the group would like to poll the community to gage preferences.

Please complete the poll below by 5pm PDT on Wednesday, March 14


Thank you,


Brett

--
Brett Preston
The Linux Foundation
+1 (971) 303-9030
bpreston@...

Google Talk: bpreston@...
Skype: bprestoncf

Re: Regarding Base Functionality in Core Services

Steve Osselton
 

He Trevor,

Sounds good how about "util" for a package?

Cheers Steve


On 9 Mar 2018 00:36, <Trevor.Conn@...> wrote:

Hi folks -- With my most recent PR in the edgex-go repo I've started to consolidate some of the code repetition involved in bootstrapping the core services. For this particular PR, the target is the heartbeat functionality. As you can see, I moved the logic into a support/heartbeat package with is then called via one line in the main.go of each service.


heartbeat.Start(configuration.HeartBeatMsg, configuration.HeartBeatTime, loggingClient)


I don't necessarily think this is the best place for it, but it will do for now. We don't particularly have a good place in the package structure for common, base functionality required by all services in EdgeX. As Jim explained it to me, "support" is meant for optional services (like logging and notifications) so to me, the support package should be concerned solely with the implementation of these services (like "core" or "export"). So if we have functionality that cuts across all services, like a heartbeat or perhaps configuration, where should it go?


We should probably avoid overly broad terms like "common" or "libs". I don't know. "Service-base" or "aspects"? I'm concerned that "support" will become a dumping ground for miscellaneous stuff.


If anyone has any thoughts, let me know.


Also, please note that LoggingClient is now an interface. The heartbeat implementation receives this interface as a parameter and the unit test has its own mock implementation. I'll be emphasizing decoupling and unit testing as I make more changes.


Thanks,

Trevor



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