Jan- No need to apologize! One of my favorite things about open source is that we solve problems for each other and can improve on each solutions.
I’m really glad you took the time to move those mid rewrite params out into a separate profile and even happier that there was automation for it. We have some different goals than you do, so we’re glad to iterate on this and hopefully contribute something useful for others in a similar position to us —Eric > On Sep 14, 2017, at 12:20 PM, Jan van Doorn <[email protected]> wrote: > > 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) <[email protected]> >> 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 >> >> >
