Removing installation dependencies

2017-09-14 Thread Eric Friedrich (efriedri)
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




Re: Removing installation dependencies

2017-09-14 Thread Jan van Doorn
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)  
> 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
> 
> 



Re: Removing installation dependencies

2017-09-14 Thread Robert Butts
Seconded. Definitely +1 if you can do that migration in SQL. I think it's
possible, but not easy. CTEs/With should help. But I wouldn't be -1 on (2)
if you decide (1) isn't feasible.

On Thu, Sep 14, 2017 at 10:20 AM, Jan van Doorn  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) <
> 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
> >
> >
>
>


Re: Removing installation dependencies

2017-09-15 Thread Eric Friedrich (efriedri)
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  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)  
>> 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
>> 
>> 
>