You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Eric Friedrich (efriedri)" <ef...@cisco.com> on 2017/09/14 16:06:52 UTC
Removing installation dependencies
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
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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 <jv...@knutsel.com> 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) <ef...@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
Posted by Robert Butts <ro...@gmail.com>.
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 <jv...@knutsel.com> 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) <
> efriedri@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
Posted by Jan van Doorn <jv...@knutsel.com>.
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) <ef...@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
>
>