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 <[email protected]> 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 <[email protected]> wrote: > > > uhh... never mind > > > > On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <[email protected]> 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 < > > > [email protected]> 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" <[email protected]> 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 > > >> > > >> > > >> > >
