It's not a trivial problem. Yes -- we could include the source -- goose itself is actually fairly small and MIT licensed. Its dependencies have licenses that would need to be vetted, so vendoring is also not trivial -- no matter how many lines of code are involved.
We could potentially compile goose and distribute within the rpm -- I've also suggested that before. Unfortunately, we have a migration written in go, which requires a go installation at run time. That means the requirement of a go installation is not avoidable without rewriting that as .sql. There are alternatives we could use that may not suffer from the same issues. I suggest we sit down together at the Summit and decide where to go with this.. -dan On Mon, May 1, 2017 at 10:37 AM, Robert Butts <robert.o.bu...@gmail.com> wrote: > +1 on Vendoring. I don't see a difference if it's 375,000 lines or > 10,000,000 lines. What does it matter if it's 375k lines in someone else's > repo or our own? It does matter from a security standpoint. It means we're > now vulnerable if their repo is compromised. We shouldn't be pulling > _anything_ from the internet at install time. > > Question for the Apache Gurus: If we include the Goose source, can we also > include a binary built from that source? I don't see a legal or > philosophical reason we shouldn't be able to, if we include a hash of the > binary and the LICENSE file. That lets us avoid requiring Go as a > dependency, which is difficult since few package managers have a modern Go > package. Goose is MIT, > https://www.apache.org/dev/licensing-howto.html#binary suggests we can, yes? > > > On Mon, May 1, 2017 at 8:31 AM, Dan Kirkwood <dang...@gmail.com> wrote: > >> ughh.. I'd forgotten I'd done that in all this.. >> >> Again -- catch-22. >> >> >> >> On Sun, Apr 30, 2017 at 10:20 PM, Mark Torluemke <mtorlue...@apache.org> >> wrote: >> > On Sun, Apr 30, 2017 at 7:05 PM, Gelinas, Derek < >> derek_geli...@comcast.com> >> > wrote: >> > >> >> +1 on both of these. >> >> >> >> > On Apr 30, 2017, at 8:50 PM, Eric Friedrich (efriedri) < >> >> efrie...@cisco.com> wrote: >> >> > >> >> > Assuming we stick with goose, why not bundle goose source into the >> >> traffic ops RPM? This will pin the version for us and prevent users from >> >> needing to run go get >> >> >> > >> > Dan had put in a PR to add the Goose source: >> > https://github.com/apache/incubator-trafficcontrol/pull/157 >> > >> > We ended up closing it, as 375,000 lines felt a bit excessive... >> > >> > >> > >> >> > >> >> > We are allowed to bundle code with the MIT license into our releases. >> >> > >> >> > As for the go installation, what about modifying the RPM spec file to >> >> list GoLang as a dependency of the traffic ops RPM? >> >> > >> >> > —Eric >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> On Apr 28, 2017, at 4:46 PM, Dewayne Richardson <dewr...@gmail.com> >> >> wrote: >> >> >> >> >> >> They are, but makes the tooling easier if we are all in Golang >> >> >> >> >> >>> On Fri, Apr 28, 2017 at 1:44 PM, Dave Neuman <neu...@apache.org> >> >> wrote: >> >> >>> >> >> >>> I don't see why re-writing the APIs in something like golang would >> mean >> >> >>> that we also need to re-write the database admin script. I think >> >> those two >> >> >>> things are mutually exclusive, right? >> >> >>> >> >> >>> On Fri, Apr 28, 2017 at 12:29 PM, Dewayne Richardson < >> >> dewr...@gmail.com> >> >> >>> wrote: >> >> >>> >> >> >>>> I had that thought, as well as there are more recent versions like >> >> >>>> https://github.com/mattes/migrate. The question becomes if we >> ever >> >> get >> >> >>>> around to rewriting TrafficOps APIs in golang, will the Perl >> version >> >> then >> >> >>>> become obsolete? >> >> >>>> >> >> >>>>> On Fri, Apr 28, 2017 at 11:58 AM, Dave Neuman <neu...@apache.org> >> >> wrote: >> >> >>>>> >> >> >>>>> Maybe it's time we take a look at what goose really buys us and >> >> >>> consider >> >> >>>>> writing our own database migration tool. We already have >> admin.pl, >> >> it >> >> >>>>> could probably fit in with that? >> >> >>>>> >> >> >>>>> On Fri, Apr 28, 2017 at 11:45 AM, Eric Friedrich (efriedri) < >> >> >>>>> efrie...@cisco.com> wrote: >> >> >>>>> >> >> >>>>>> Hey Dew- >> >> >>>>>> What calls this script? >> >> >>>>>> >> >> >>>>>> If its called from the Traffic Ops Spec file, then this will >> cause >> >> >>> some >> >> >>>>>> pain for those of us that need to install without internet >> access. >> >> >>>>>> >> >> >>>>>> —Eric >> >> >>>>>> >> >> >>>>>>> On Apr 28, 2017, at 12:41 PM, Dewayne Richardson < >> >> >>> dewr...@gmail.com> >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> I'm working toward a more streamlined installation process for >> >> >>>> Traffic >> >> >>>>>> Ops >> >> >>>>>>> (internally) and publicly. Of course, the same hiccups that >> >> >>> everyone >> >> >>>>> else >> >> >>>>>>> runs into I am as well. Installation of Golang (proper version) >> >> >>> and >> >> >>>>>>> installation of Goose. Goose has been the most challenging for >> >> >>>> several >> >> >>>>>>> reasons. The maintainer hasn't made any real changes since >> 2015, >> >> >>> and >> >> >>>>> has >> >> >>>>>>> not "branched" his code to allow for explicit version download. >> >> >>> Per >> >> >>>>> his >> >> >>>>>>> installation instructions "go get >> bitbucket.org/liamstask/goose/ >> >> >>>>>> cmd/goose" >> >> >>>>>>> >> >> >>>>>>> So I'm I'm proposing to write an installer script in bash to >> help >> >> >>>>>> automate >> >> >>>>>>> the Golang install as well as the Goose install. My only >> concern >> >> >>> (as >> >> >>>>>> well >> >> >>>>>>> as most of yours) is "go get" will grab the latest, but since no >> >> >>> real >> >> >>>>>>> changes have happened I'm left with no other option. >> >> >>>>>>> >> >> >>>>>>> Proposed: >> >> >>>>>>> >> >> >>>>>>> /opt/traffic_ops/install/bin/install_goose.sh >> >> >>>>>>> >> >> >>>>>>> - Install Golang (version 1.8.x) >> >> >>>>>>> - go get bitbucket.org/liamstask/goose/cmd/goose >> >> >>>>>>> >> >> >>>>>>> Thoughts? >> >> >>>>>>> >> >> >>>>>>> -Dew >> >> >>>>>> >> >> >>>>>> >> >> >>>>> >> >> >>>> >> >> >>> >> >> > >> >> >>
