The go migration is my fault…. I couldn’t figure out how to do some of that stuff in SQL, and I think anyone would be hard pressed to do that.
Wasn’t aware we need the go compiler for that when I went down that path though. Maybe another alternative is to make a “light migration”? Here’s my thinking - if I remember correctly most of that go code deals with the MSO config moving from parameter overrides in header_rewrite to parent.config. If you don’t have MSO, or are willing to migrate that stuff by hand, we can create a simple SQL migration that just does the schema changes… I’ll be more careful pulling in something new like that next time, sorry… Cheers, JvD > On Sep 14, 2017, at 10:06 AM, Eric Friedrich (efriedri) <efrie...@cisco.com> > wrote: > > As we’re moving to TC2.1, we’ve found that the goose migration requires not > just the goose binary to be installed, but also the go compiler and a fairly > large set of dependencies. Most of these are a result of the migration of the > MSO parent_retry parameters from the DS table into the profile_parameters > table. > > We have a very hard requirement that our product CANNOT require Internet > access for installation. > > We’d like to avoid vendoring (in one form or another) all of the goose > dependencies, the same way we’ve had to do with web-deps and CPAN. > > We are considering two solutions: > 1) Replace the .go migration with a PL/SQL file that does not require all of > the go dependencies. In this case we would compile goose and ship it as a > binary in our RPM to eliminate the ‘go get goose' > > 2) Switch to a different fork of goose (https://github.com/pressly/goose) > that can execute binary migrations. Here we would compile the .go migration > into a binary and ship both the new goose binary and the migration binary in > our RPM. > > —Eric > >
