You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Dan Kirkwood <da...@apache.org> on 2018/06/07 21:27:06 UTC
go version used in build
Hey, all.. I just investigated this issue (
https://github.com/apache/incubator-trafficcontrol/issues/2380) and
realized that the `go` version being used in building traffic_stats and
traffic_monitor is different from that of traffic_ops due to the way it's
installed during the rpmbuild phase. In traffic_ops, a specific version
(1.8.3) is downloaded using a script; the others depend on yum without
specifying a version (currently 1.9.4).
Should we worry about keeping these in line? If so, should we:
1. change TO to install latest version from yum?
2. change TS and TM to use the script?
3. change all to install a specific version from yum?
Currently leaning toward #1, but I can be convinced otherwise..
thanks.. Dan
Re: go version used in build
Posted by Dewayne Richardson <de...@apache.org>.
I vote for #3 because it'll help with Ops to stay on top of keeping the yum
repo's consistent.
-Dew
On Thu, Jun 7, 2018 at 3:27 PM Dan Kirkwood <da...@apache.org> wrote:
> Hey, all.. I just investigated this issue (
> https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> realized that the `go` version being used in building traffic_stats and
> traffic_monitor is different from that of traffic_ops due to the way it's
> installed during the rpmbuild phase. In traffic_ops, a specific version
> (1.8.3) is downloaded using a script; the others depend on yum without
> specifying a version (currently 1.9.4).
>
> Should we worry about keeping these in line? If so, should we:
>
> 1. change TO to install latest version from yum?
> 2. change TS and TM to use the script?
> 3. change all to install a specific version from yum?
>
> Currently leaning toward #1, but I can be convinced otherwise..
>
> thanks.. Dan
>
Re: [EXTERNAL] go version used in build
Posted by "Volz, Dylan" <Dy...@comcast.com>.
#3 has the benefits of consistent builds and controlling the version but the risk of us setting and forgetting it increases, and we could fall far behind.
Given that I would vote for #3 and push for us to stay up to date. (+1 on common go builder.)
On 6/8/18, 8:15 AM, "Dave Neuman" <ne...@apache.org> wrote:
I prefer #1 since that seems like the easiest, however that could lead to
inconsistent builds and make it hard to support our products, so I think #3
is probably a better option.
If we chose to go with #3 then I like Erics idea of making a common go
builder so that we only need to manage the version in one place and not
three (or more in the future).
On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) <ef...@cisco.com>
wrote:
> Should we look into creating a common “go builder” container base image
> that can be shared by all of the go components?
>
> It would be easier to keep this in a common location rather than having to
> keep a bunch of Dockerfiles in sync.
>
> —Eric
>
>
> > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <Ev...@comcast.com>
> wrote:
> >
> > +1 on 3. I thought there were some changes made in 1.10 that have the
> possibility of breaking things, i.e. I think it breaks some of Grove. They
> may or may not affect TC but who knows what might happen in the future. So
> I would think you would want the version pinned
> > ________________________________________
> > From: Gray, Jonathan <Jo...@comcast.com>
> > Sent: Thursday, June 7, 2018 4:53 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: Re: [EXTERNAL] go version used in build
> >
> > I vote for option 3 since the version of go you compile with is no
> different than the version of a library used in the build process. By
> specifying what version it shall be, we also know when we go to newer
> versions and have more reproducible builds.
> >
> > On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
> >
> > Hey, all.. I just investigated this issue (
> > https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> > realized that the `go` version being used in building traffic_stats
> and
> > traffic_monitor is different from that of traffic_ops due to the way
> it's
> > installed during the rpmbuild phase. In traffic_ops, a specific
> version
> > (1.8.3) is downloaded using a script; the others depend on yum
> without
> > specifying a version (currently 1.9.4).
> >
> > Should we worry about keeping these in line? If so, should we:
> >
> > 1. change TO to install latest version from yum?
> > 2. change TS and TM to use the script?
> > 3. change all to install a specific version from yum?
> >
> > Currently leaning toward #1, but I can be convinced otherwise..
> >
> > thanks.. Dan
> >
> >
>
>
Re: [EXTERNAL] go version used in build
Posted by Jeff Elsloo <el...@apache.org>.
I concur with the assessment that option #1 is easiest to achieve, but
#3 is more desirable due to predictability when producing a build. I
too prefer option #3, while acknowledging it could be more effort to
implement.
--
Thanks,
Jeff
On Fri, Jun 8, 2018 at 11:19 AM, Dan Kirkwood <da...@gmail.com> wrote:
> btw, not going to act on this right now, so there still is time to
> provide your input.
>
> On Fri, Jun 8, 2018 at 11:17 AM Dan Kirkwood <da...@gmail.com> wrote:
>
>> Thanks, Dave -- that's where I stand as well -- preferring #1 but knowing
>> that #3 is probably the necessary option.. I like the common go build
>> idea, but can't spend the time on it now.
>>
>> Going for consensus.. Can everyone live with #3 (yum install golang
>> with specific version for all components)?
>>
>> Please speak up....
>>
>> -dan
>>
>> On Fri, Jun 8, 2018 at 8:15 AM Dave Neuman <ne...@apache.org> wrote:
>>
>>> I prefer #1 since that seems like the easiest, however that could lead to
>>> inconsistent builds and make it hard to support our products, so I think
>>> #3
>>> is probably a better option.
>>>
>>> If we chose to go with #3 then I like Erics idea of making a common go
>>> builder so that we only need to manage the version in one place and not
>>> three (or more in the future).
>>>
>>>
>>> On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) <
>>> efriedri@cisco.com>
>>> wrote:
>>>
>>> > Should we look into creating a common “go builder” container base image
>>> > that can be shared by all of the go components?
>>> >
>>> > It would be easier to keep this in a common location rather than having
>>> to
>>> > keep a bunch of Dockerfiles in sync.
>>> >
>>> > —Eric
>>> >
>>> >
>>> > > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <
>>> Evan_Zelkowitz@comcast.com>
>>> > wrote:
>>> > >
>>> > > +1 on 3. I thought there were some changes made in 1.10 that have the
>>> > possibility of breaking things, i.e. I think it breaks some of Grove.
>>> They
>>> > may or may not affect TC but who knows what might happen in the future.
>>> So
>>> > I would think you would want the version pinned
>>> > > ________________________________________
>>> > > From: Gray, Jonathan <Jo...@comcast.com>
>>> > > Sent: Thursday, June 7, 2018 4:53 PM
>>> > > To: dev@trafficcontrol.apache.org
>>> > > Subject: Re: [EXTERNAL] go version used in build
>>> > >
>>> > > I vote for option 3 since the version of go you compile with is no
>>> > different than the version of a library used in the build process. By
>>> > specifying what version it shall be, we also know when we go to newer
>>> > versions and have more reproducible builds.
>>> > >
>>> > > On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
>>> > >
>>> > > Hey, all.. I just investigated this issue (
>>> > > https://github.com/apache/incubator-trafficcontrol/issues/2380)
>>> and
>>> > > realized that the `go` version being used in building traffic_stats
>>> > and
>>> > > traffic_monitor is different from that of traffic_ops due to the
>>> way
>>> > it's
>>> > > installed during the rpmbuild phase. In traffic_ops, a specific
>>> > version
>>> > > (1.8.3) is downloaded using a script; the others depend on yum
>>> > without
>>> > > specifying a version (currently 1.9.4).
>>> > >
>>> > > Should we worry about keeping these in line? If so, should we:
>>> > >
>>> > > 1. change TO to install latest version from yum?
>>> > > 2. change TS and TM to use the script?
>>> > > 3. change all to install a specific version from yum?
>>> > >
>>> > > Currently leaning toward #1, but I can be convinced otherwise..
>>> > >
>>> > > thanks.. Dan
>>> > >
>>> > >
>>> >
>>> >
>>>
>>
Re: [EXTERNAL] go version used in build
Posted by Dan Kirkwood <da...@gmail.com>.
btw, not going to act on this right now, so there still is time to
provide your input.
On Fri, Jun 8, 2018 at 11:17 AM Dan Kirkwood <da...@gmail.com> wrote:
> Thanks, Dave -- that's where I stand as well -- preferring #1 but knowing
> that #3 is probably the necessary option.. I like the common go build
> idea, but can't spend the time on it now.
>
> Going for consensus.. Can everyone live with #3 (yum install golang
> with specific version for all components)?
>
> Please speak up....
>
> -dan
>
> On Fri, Jun 8, 2018 at 8:15 AM Dave Neuman <ne...@apache.org> wrote:
>
>> I prefer #1 since that seems like the easiest, however that could lead to
>> inconsistent builds and make it hard to support our products, so I think
>> #3
>> is probably a better option.
>>
>> If we chose to go with #3 then I like Erics idea of making a common go
>> builder so that we only need to manage the version in one place and not
>> three (or more in the future).
>>
>>
>> On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) <
>> efriedri@cisco.com>
>> wrote:
>>
>> > Should we look into creating a common “go builder” container base image
>> > that can be shared by all of the go components?
>> >
>> > It would be easier to keep this in a common location rather than having
>> to
>> > keep a bunch of Dockerfiles in sync.
>> >
>> > —Eric
>> >
>> >
>> > > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <
>> Evan_Zelkowitz@comcast.com>
>> > wrote:
>> > >
>> > > +1 on 3. I thought there were some changes made in 1.10 that have the
>> > possibility of breaking things, i.e. I think it breaks some of Grove.
>> They
>> > may or may not affect TC but who knows what might happen in the future.
>> So
>> > I would think you would want the version pinned
>> > > ________________________________________
>> > > From: Gray, Jonathan <Jo...@comcast.com>
>> > > Sent: Thursday, June 7, 2018 4:53 PM
>> > > To: dev@trafficcontrol.apache.org
>> > > Subject: Re: [EXTERNAL] go version used in build
>> > >
>> > > I vote for option 3 since the version of go you compile with is no
>> > different than the version of a library used in the build process. By
>> > specifying what version it shall be, we also know when we go to newer
>> > versions and have more reproducible builds.
>> > >
>> > > On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
>> > >
>> > > Hey, all.. I just investigated this issue (
>> > > https://github.com/apache/incubator-trafficcontrol/issues/2380)
>> and
>> > > realized that the `go` version being used in building traffic_stats
>> > and
>> > > traffic_monitor is different from that of traffic_ops due to the
>> way
>> > it's
>> > > installed during the rpmbuild phase. In traffic_ops, a specific
>> > version
>> > > (1.8.3) is downloaded using a script; the others depend on yum
>> > without
>> > > specifying a version (currently 1.9.4).
>> > >
>> > > Should we worry about keeping these in line? If so, should we:
>> > >
>> > > 1. change TO to install latest version from yum?
>> > > 2. change TS and TM to use the script?
>> > > 3. change all to install a specific version from yum?
>> > >
>> > > Currently leaning toward #1, but I can be convinced otherwise..
>> > >
>> > > thanks.. Dan
>> > >
>> > >
>> >
>> >
>>
>
Re: [EXTERNAL] go version used in build
Posted by Dan Kirkwood <da...@gmail.com>.
Thanks, Dave -- that's where I stand as well -- preferring #1 but knowing
that #3 is probably the necessary option.. I like the common go build
idea, but can't spend the time on it now.
Going for consensus.. Can everyone live with #3 (yum install golang with
specific version for all components)?
Please speak up....
-dan
On Fri, Jun 8, 2018 at 8:15 AM Dave Neuman <ne...@apache.org> wrote:
> I prefer #1 since that seems like the easiest, however that could lead to
> inconsistent builds and make it hard to support our products, so I think #3
> is probably a better option.
>
> If we chose to go with #3 then I like Erics idea of making a common go
> builder so that we only need to manage the version in one place and not
> three (or more in the future).
>
>
> On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) <
> efriedri@cisco.com>
> wrote:
>
> > Should we look into creating a common “go builder” container base image
> > that can be shared by all of the go components?
> >
> > It would be easier to keep this in a common location rather than having
> to
> > keep a bunch of Dockerfiles in sync.
> >
> > —Eric
> >
> >
> > > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <
> Evan_Zelkowitz@comcast.com>
> > wrote:
> > >
> > > +1 on 3. I thought there were some changes made in 1.10 that have the
> > possibility of breaking things, i.e. I think it breaks some of Grove.
> They
> > may or may not affect TC but who knows what might happen in the future.
> So
> > I would think you would want the version pinned
> > > ________________________________________
> > > From: Gray, Jonathan <Jo...@comcast.com>
> > > Sent: Thursday, June 7, 2018 4:53 PM
> > > To: dev@trafficcontrol.apache.org
> > > Subject: Re: [EXTERNAL] go version used in build
> > >
> > > I vote for option 3 since the version of go you compile with is no
> > different than the version of a library used in the build process. By
> > specifying what version it shall be, we also know when we go to newer
> > versions and have more reproducible builds.
> > >
> > > On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
> > >
> > > Hey, all.. I just investigated this issue (
> > > https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> > > realized that the `go` version being used in building traffic_stats
> > and
> > > traffic_monitor is different from that of traffic_ops due to the way
> > it's
> > > installed during the rpmbuild phase. In traffic_ops, a specific
> > version
> > > (1.8.3) is downloaded using a script; the others depend on yum
> > without
> > > specifying a version (currently 1.9.4).
> > >
> > > Should we worry about keeping these in line? If so, should we:
> > >
> > > 1. change TO to install latest version from yum?
> > > 2. change TS and TM to use the script?
> > > 3. change all to install a specific version from yum?
> > >
> > > Currently leaning toward #1, but I can be convinced otherwise..
> > >
> > > thanks.. Dan
> > >
> > >
> >
> >
>
Re: [EXTERNAL] go version used in build
Posted by Dave Neuman <ne...@apache.org>.
I prefer #1 since that seems like the easiest, however that could lead to
inconsistent builds and make it hard to support our products, so I think #3
is probably a better option.
If we chose to go with #3 then I like Erics idea of making a common go
builder so that we only need to manage the version in one place and not
three (or more in the future).
On Fri, Jun 8, 2018 at 6:41 AM Eric Friedrich (efriedri) <ef...@cisco.com>
wrote:
> Should we look into creating a common “go builder” container base image
> that can be shared by all of the go components?
>
> It would be easier to keep this in a common location rather than having to
> keep a bunch of Dockerfiles in sync.
>
> —Eric
>
>
> > On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <Ev...@comcast.com>
> wrote:
> >
> > +1 on 3. I thought there were some changes made in 1.10 that have the
> possibility of breaking things, i.e. I think it breaks some of Grove. They
> may or may not affect TC but who knows what might happen in the future. So
> I would think you would want the version pinned
> > ________________________________________
> > From: Gray, Jonathan <Jo...@comcast.com>
> > Sent: Thursday, June 7, 2018 4:53 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: Re: [EXTERNAL] go version used in build
> >
> > I vote for option 3 since the version of go you compile with is no
> different than the version of a library used in the build process. By
> specifying what version it shall be, we also know when we go to newer
> versions and have more reproducible builds.
> >
> > On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
> >
> > Hey, all.. I just investigated this issue (
> > https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> > realized that the `go` version being used in building traffic_stats
> and
> > traffic_monitor is different from that of traffic_ops due to the way
> it's
> > installed during the rpmbuild phase. In traffic_ops, a specific
> version
> > (1.8.3) is downloaded using a script; the others depend on yum
> without
> > specifying a version (currently 1.9.4).
> >
> > Should we worry about keeping these in line? If so, should we:
> >
> > 1. change TO to install latest version from yum?
> > 2. change TS and TM to use the script?
> > 3. change all to install a specific version from yum?
> >
> > Currently leaning toward #1, but I can be convinced otherwise..
> >
> > thanks.. Dan
> >
> >
>
>
Re: [EXTERNAL] go version used in build
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Should we look into creating a common “go builder” container base image that can be shared by all of the go components?
It would be easier to keep this in a common location rather than having to keep a bunch of Dockerfiles in sync.
—Eric
> On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan <Ev...@comcast.com> wrote:
>
> +1 on 3. I thought there were some changes made in 1.10 that have the possibility of breaking things, i.e. I think it breaks some of Grove. They may or may not affect TC but who knows what might happen in the future. So I would think you would want the version pinned
> ________________________________________
> From: Gray, Jonathan <Jo...@comcast.com>
> Sent: Thursday, June 7, 2018 4:53 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] go version used in build
>
> I vote for option 3 since the version of go you compile with is no different than the version of a library used in the build process. By specifying what version it shall be, we also know when we go to newer versions and have more reproducible builds.
>
> On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
>
> Hey, all.. I just investigated this issue (
> https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> realized that the `go` version being used in building traffic_stats and
> traffic_monitor is different from that of traffic_ops due to the way it's
> installed during the rpmbuild phase. In traffic_ops, a specific version
> (1.8.3) is downloaded using a script; the others depend on yum without
> specifying a version (currently 1.9.4).
>
> Should we worry about keeping these in line? If so, should we:
>
> 1. change TO to install latest version from yum?
> 2. change TS and TM to use the script?
> 3. change all to install a specific version from yum?
>
> Currently leaning toward #1, but I can be convinced otherwise..
>
> thanks.. Dan
>
>
Re: [EXTERNAL] go version used in build
Posted by "Zelkowitz, Evan" <Ev...@comcast.com>.
+1 on 3. I thought there were some changes made in 1.10 that have the possibility of breaking things, i.e. I think it breaks some of Grove. They may or may not affect TC but who knows what might happen in the future. So I would think you would want the version pinned
________________________________________
From: Gray, Jonathan <Jo...@comcast.com>
Sent: Thursday, June 7, 2018 4:53 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] go version used in build
I vote for option 3 since the version of go you compile with is no different than the version of a library used in the build process. By specifying what version it shall be, we also know when we go to newer versions and have more reproducible builds.
On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
Hey, all.. I just investigated this issue (
https://github.com/apache/incubator-trafficcontrol/issues/2380) and
realized that the `go` version being used in building traffic_stats and
traffic_monitor is different from that of traffic_ops due to the way it's
installed during the rpmbuild phase. In traffic_ops, a specific version
(1.8.3) is downloaded using a script; the others depend on yum without
specifying a version (currently 1.9.4).
Should we worry about keeping these in line? If so, should we:
1. change TO to install latest version from yum?
2. change TS and TM to use the script?
3. change all to install a specific version from yum?
Currently leaning toward #1, but I can be convinced otherwise..
thanks.. Dan
Re: [EXTERNAL] go version used in build
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
I vote for option 3 since the version of go you compile with is no different than the version of a library used in the build process. By specifying what version it shall be, we also know when we go to newer versions and have more reproducible builds.
On 6/7/18, 3:27 PM, "Dan Kirkwood" <da...@apache.org> wrote:
Hey, all.. I just investigated this issue (
https://github.com/apache/incubator-trafficcontrol/issues/2380) and
realized that the `go` version being used in building traffic_stats and
traffic_monitor is different from that of traffic_ops due to the way it's
installed during the rpmbuild phase. In traffic_ops, a specific version
(1.8.3) is downloaded using a script; the others depend on yum without
specifying a version (currently 1.9.4).
Should we worry about keeping these in line? If so, should we:
1. change TO to install latest version from yum?
2. change TS and TM to use the script?
3. change all to install a specific version from yum?
Currently leaning toward #1, but I can be convinced otherwise..
thanks.. Dan
Re: go version used in build
Posted by Steve Malenfant <sm...@gmail.com>.
I vote on option 1.
Steve
On Thu, Jun 7, 2018 at 5:27 PM Dan Kirkwood <da...@apache.org> wrote:
> Hey, all.. I just investigated this issue (
> https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> realized that the `go` version being used in building traffic_stats and
> traffic_monitor is different from that of traffic_ops due to the way it's
> installed during the rpmbuild phase. In traffic_ops, a specific version
> (1.8.3) is downloaded using a script; the others depend on yum without
> specifying a version (currently 1.9.4).
>
> Should we worry about keeping these in line? If so, should we:
>
> 1. change TO to install latest version from yum?
> 2. change TS and TM to use the script?
> 3. change all to install a specific version from yum?
>
> Currently leaning toward #1, but I can be convinced otherwise..
>
> thanks.. Dan
>