You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Rawlin Peters <ra...@apache.org> on 2019/11/20 21:17:48 UTC
Go version for components other than TO
Hey all,
The Go version for building Traffic Ops is currently pinned to 1.11
due to issues communicating with Riak when using 1.12 or 1.13. All of
the other Go components are currently built using the version provided
by the `golang` package from EPEL, which is currently 1.13.3.
My question is: are we content keeping all non-TO Go components using
the version provided by EPEL, since we haven't really identified an
issue using 1.13 for those components (although I'm not sure they've
really been "vetted" by anyone yet), or do we pin them back to 1.11
since that is the "vetted" version?
These are some of the options I can see:
1. leave non-TO Go component builds as-is, they will use whatever
version is provided by EPEL (might catch us off-guard, but we'll stay
up to date by default)
2. pin the rest of the non-TO Go components to 1.11 (since that
version is "vetted") then advance versions for components only after
thorough testing
3. pin some Go components to 1.11, optimistically pin others to 1.13
if they're not as production critical
Advancing components to new versions of Go seems like something that
should be deliberate and tested, so I'd lean towards Option 2 for the
time being. What option do you think is best?
- Rawlin
Re: [EXTERNAL] Go version for components other than TO
Posted by Rawlin Peters <ra...@apache.org>.
Alright, I'll throw together a PR that pins the Go version to 1.11 for
the rest of the components. Hopefully, we will be able to fix the
TO-Riak communication issue to advance TO to 1.13 soon, then we can
purposefully test 1.13 for the rest of the Go components as well. I do
like Michael's idea of using the same Go version across all of our Go
components.
- Rawlin
On Wed, Nov 20, 2019 at 6:06 PM Robert O Butts <ro...@apache.org> wrote:
>
> +1 on pinning the version on everything. Unpredictability and
> nondeterminism is bad.
>
> I don't have a strong opinion on which version. Though later versions of Go
> frequently have performance improvements, sometimes huge ones, which can
> matter for our performance-intensive apps like the Monitor and Grove.
>
>
> On Wed, Nov 20, 2019 at 4:47 PM ocket 8888 <oc...@gmail.com> wrote:
>
> > uhh... never mind
> >
> > On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <oc...@gmail.com> wrote:
> >
> > > The routes don't need to be regular expressions though. That's a change
> > > that still needs to be made, and while it would have other benefits
> > beyond
> > > this whitelist/blacklist, it is a significant amount of work that may or
> > > may not be more than the work of getting regular expressions to work, so
> > > idk if you wanna do that but it's true. Then, as far as path parameters,
> > > you can just strip them before comparison by doing something like
> > >
> > > regex.MustCompile(`\{[^\}]+\}`).Replace(path, "")
> > >
> > > not actually familiar with that api, but the point is that comparisons
> > can
> > > be made to ignore path parameters probably pretty easily - as long as
> > they
> > > are just strings.
> > >
> > > On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael <
> > > Michael_Hoppal@comcast.com> wrote:
> > >
> > >> I am in agreeance here and +1 on Option 2.
> > >>
> > >> Not only is the version "vetted" but also keeps our Go version for
> > >> building consistent across services that are in the same repository
> > which I
> > >> think is of value as well. I know personally when I am developing I am
> > >> probably not going to remember to switch my go version as I switch
> > between
> > >> services.
> > >>
> > >> Michael
> > >>
> > >> On 11/20/19, 2:18 PM, "Rawlin Peters" <ra...@apache.org> wrote:
> > >>
> > >> Hey all,
> > >>
> > >> The Go version for building Traffic Ops is currently pinned to 1.11
> > >> due to issues communicating with Riak when using 1.12 or 1.13. All
> > of
> > >> the other Go components are currently built using the version
> > provided
> > >> by the `golang` package from EPEL, which is currently 1.13.3.
> > >>
> > >> My question is: are we content keeping all non-TO Go components
> > using
> > >> the version provided by EPEL, since we haven't really identified an
> > >> issue using 1.13 for those components (although I'm not sure they've
> > >> really been "vetted" by anyone yet), or do we pin them back to 1.11
> > >> since that is the "vetted" version?
> > >>
> > >> These are some of the options I can see:
> > >> 1. leave non-TO Go component builds as-is, they will use whatever
> > >> version is provided by EPEL (might catch us off-guard, but we'll
> > stay
> > >> up to date by default)
> > >> 2. pin the rest of the non-TO Go components to 1.11 (since that
> > >> version is "vetted") then advance versions for components only after
> > >> thorough testing
> > >> 3. pin some Go components to 1.11, optimistically pin others to 1.13
> > >> if they're not as production critical
> > >>
> > >> Advancing components to new versions of Go seems like something that
> > >> should be deliberate and tested, so I'd lean towards Option 2 for
> > the
> > >> time being. What option do you think is best?
> > >>
> > >> - Rawlin
> > >>
> > >>
> > >>
> >
Re: [EXTERNAL] Go version for components other than TO
Posted by Robert O Butts <ro...@apache.org>.
+1 on pinning the version on everything. Unpredictability and
nondeterminism is bad.
I don't have a strong opinion on which version. Though later versions of Go
frequently have performance improvements, sometimes huge ones, which can
matter for our performance-intensive apps like the Monitor and Grove.
On Wed, Nov 20, 2019 at 4:47 PM ocket 8888 <oc...@gmail.com> wrote:
> uhh... never mind
>
> On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <oc...@gmail.com> wrote:
>
> > The routes don't need to be regular expressions though. That's a change
> > that still needs to be made, and while it would have other benefits
> beyond
> > this whitelist/blacklist, it is a significant amount of work that may or
> > may not be more than the work of getting regular expressions to work, so
> > idk if you wanna do that but it's true. Then, as far as path parameters,
> > you can just strip them before comparison by doing something like
> >
> > regex.MustCompile(`\{[^\}]+\}`).Replace(path, "")
> >
> > not actually familiar with that api, but the point is that comparisons
> can
> > be made to ignore path parameters probably pretty easily - as long as
> they
> > are just strings.
> >
> > On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael <
> > Michael_Hoppal@comcast.com> wrote:
> >
> >> I am in agreeance here and +1 on Option 2.
> >>
> >> Not only is the version "vetted" but also keeps our Go version for
> >> building consistent across services that are in the same repository
> which I
> >> think is of value as well. I know personally when I am developing I am
> >> probably not going to remember to switch my go version as I switch
> between
> >> services.
> >>
> >> Michael
> >>
> >> On 11/20/19, 2:18 PM, "Rawlin Peters" <ra...@apache.org> wrote:
> >>
> >> Hey all,
> >>
> >> The Go version for building Traffic Ops is currently pinned to 1.11
> >> due to issues communicating with Riak when using 1.12 or 1.13. All
> of
> >> the other Go components are currently built using the version
> provided
> >> by the `golang` package from EPEL, which is currently 1.13.3.
> >>
> >> My question is: are we content keeping all non-TO Go components
> using
> >> the version provided by EPEL, since we haven't really identified an
> >> issue using 1.13 for those components (although I'm not sure they've
> >> really been "vetted" by anyone yet), or do we pin them back to 1.11
> >> since that is the "vetted" version?
> >>
> >> These are some of the options I can see:
> >> 1. leave non-TO Go component builds as-is, they will use whatever
> >> version is provided by EPEL (might catch us off-guard, but we'll
> stay
> >> up to date by default)
> >> 2. pin the rest of the non-TO Go components to 1.11 (since that
> >> version is "vetted") then advance versions for components only after
> >> thorough testing
> >> 3. pin some Go components to 1.11, optimistically pin others to 1.13
> >> if they're not as production critical
> >>
> >> Advancing components to new versions of Go seems like something that
> >> should be deliberate and tested, so I'd lean towards Option 2 for
> the
> >> time being. What option do you think is best?
> >>
> >> - Rawlin
> >>
> >>
> >>
>
Re: [EXTERNAL] Go version for components other than TO
Posted by ocket 8888 <oc...@gmail.com>.
uhh... never mind
On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <oc...@gmail.com> wrote:
> The routes don't need to be regular expressions though. That's a change
> that still needs to be made, and while it would have other benefits beyond
> this whitelist/blacklist, it is a significant amount of work that may or
> may not be more than the work of getting regular expressions to work, so
> idk if you wanna do that but it's true. Then, as far as path parameters,
> you can just strip them before comparison by doing something like
>
> regex.MustCompile(`\{[^\}]+\}`).Replace(path, "")
>
> not actually familiar with that api, but the point is that comparisons can
> be made to ignore path parameters probably pretty easily - as long as they
> are just strings.
>
> On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael <
> Michael_Hoppal@comcast.com> wrote:
>
>> I am in agreeance here and +1 on Option 2.
>>
>> Not only is the version "vetted" but also keeps our Go version for
>> building consistent across services that are in the same repository which I
>> think is of value as well. I know personally when I am developing I am
>> probably not going to remember to switch my go version as I switch between
>> services.
>>
>> Michael
>>
>> On 11/20/19, 2:18 PM, "Rawlin Peters" <ra...@apache.org> wrote:
>>
>> Hey all,
>>
>> The Go version for building Traffic Ops is currently pinned to 1.11
>> due to issues communicating with Riak when using 1.12 or 1.13. All of
>> the other Go components are currently built using the version provided
>> by the `golang` package from EPEL, which is currently 1.13.3.
>>
>> My question is: are we content keeping all non-TO Go components using
>> the version provided by EPEL, since we haven't really identified an
>> issue using 1.13 for those components (although I'm not sure they've
>> really been "vetted" by anyone yet), or do we pin them back to 1.11
>> since that is the "vetted" version?
>>
>> These are some of the options I can see:
>> 1. leave non-TO Go component builds as-is, they will use whatever
>> version is provided by EPEL (might catch us off-guard, but we'll stay
>> up to date by default)
>> 2. pin the rest of the non-TO Go components to 1.11 (since that
>> version is "vetted") then advance versions for components only after
>> thorough testing
>> 3. pin some Go components to 1.11, optimistically pin others to 1.13
>> if they're not as production critical
>>
>> Advancing components to new versions of Go seems like something that
>> should be deliberate and tested, so I'd lean towards Option 2 for the
>> time being. What option do you think is best?
>>
>> - Rawlin
>>
>>
>>
Re: [EXTERNAL] Go version for components other than TO
Posted by ocket 8888 <oc...@gmail.com>.
The routes don't need to be regular expressions though. That's a change
that still needs to be made, and while it would have other benefits beyond
this whitelist/blacklist, it is a significant amount of work that may or
may not be more than the work of getting regular expressions to work, so
idk if you wanna do that but it's true. Then, as far as path parameters,
you can just strip them before comparison by doing something like
regex.MustCompile(`\{[^\}]+\}`).Replace(path, "")
not actually familiar with that api, but the point is that comparisons can
be made to ignore path parameters probably pretty easily - as long as they
are just strings.
On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael <Mi...@comcast.com>
wrote:
> I am in agreeance here and +1 on Option 2.
>
> Not only is the version "vetted" but also keeps our Go version for
> building consistent across services that are in the same repository which I
> think is of value as well. I know personally when I am developing I am
> probably not going to remember to switch my go version as I switch between
> services.
>
> Michael
>
> On 11/20/19, 2:18 PM, "Rawlin Peters" <ra...@apache.org> wrote:
>
> Hey all,
>
> The Go version for building Traffic Ops is currently pinned to 1.11
> due to issues communicating with Riak when using 1.12 or 1.13. All of
> the other Go components are currently built using the version provided
> by the `golang` package from EPEL, which is currently 1.13.3.
>
> My question is: are we content keeping all non-TO Go components using
> the version provided by EPEL, since we haven't really identified an
> issue using 1.13 for those components (although I'm not sure they've
> really been "vetted" by anyone yet), or do we pin them back to 1.11
> since that is the "vetted" version?
>
> These are some of the options I can see:
> 1. leave non-TO Go component builds as-is, they will use whatever
> version is provided by EPEL (might catch us off-guard, but we'll stay
> up to date by default)
> 2. pin the rest of the non-TO Go components to 1.11 (since that
> version is "vetted") then advance versions for components only after
> thorough testing
> 3. pin some Go components to 1.11, optimistically pin others to 1.13
> if they're not as production critical
>
> Advancing components to new versions of Go seems like something that
> should be deliberate and tested, so I'd lean towards Option 2 for the
> time being. What option do you think is best?
>
> - Rawlin
>
>
>
Re: [EXTERNAL] Go version for components other than TO
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
I am in agreeance here and +1 on Option 2.
Not only is the version "vetted" but also keeps our Go version for building consistent across services that are in the same repository which I think is of value as well. I know personally when I am developing I am probably not going to remember to switch my go version as I switch between services.
Michael
On 11/20/19, 2:18 PM, "Rawlin Peters" <ra...@apache.org> wrote:
Hey all,
The Go version for building Traffic Ops is currently pinned to 1.11
due to issues communicating with Riak when using 1.12 or 1.13. All of
the other Go components are currently built using the version provided
by the `golang` package from EPEL, which is currently 1.13.3.
My question is: are we content keeping all non-TO Go components using
the version provided by EPEL, since we haven't really identified an
issue using 1.13 for those components (although I'm not sure they've
really been "vetted" by anyone yet), or do we pin them back to 1.11
since that is the "vetted" version?
These are some of the options I can see:
1. leave non-TO Go component builds as-is, they will use whatever
version is provided by EPEL (might catch us off-guard, but we'll stay
up to date by default)
2. pin the rest of the non-TO Go components to 1.11 (since that
version is "vetted") then advance versions for components only after
thorough testing
3. pin some Go components to 1.11, optimistically pin others to 1.13
if they're not as production critical
Advancing components to new versions of Go seems like something that
should be deliberate and tested, so I'd lean towards Option 2 for the
time being. What option do you think is best?
- Rawlin