> This means that the traffic_ops side would have to check to see whether traffic_ops_golang
> Because the traffic_ops_golang package will depend on traffic_ops, not the other way around I was suggesting the other way around - traffic_ops will depend on traffic_ops_golang. Which means upgrading traffic_ops automatically installs traffic_ops_golang, and we don't need to do the check. It'd mean you couldn't remove `traffic_ops_golang`, but the plan is to remove old endpoints from old TO anyway. Which is another reason making traffic_ops_golang a dependency of traffic_ops makes sense: it really is, traffic_ops really does require it for the migrated endpoints. I agree with moving away from manual post-installation scripts, but I don't think we can avoid it here, because we need the user to set a new port. On Wed, Jul 19, 2017 at 11:40 AM, Jeff Elsloo <[email protected]> wrote: > I'm +1 on most of what you suggest, except for doing the takeover in > postinstall in traffic_ops. > > While we can do whatever we want with postinstall, I think it's > awkward to have a tool within the traffic_ops package configuring > something under the traffic_ops_golang package, when the latter > package might not be installed. This means that the traffic_ops side > would have to check to see whether traffic_ops_golang is installed > outside of the normal RPM dependencies, adding more platform specific > code to postinstall. I don't see a generic way to implement the > "check" for the golang package within postinstall that will work. We > would have to check for a path that is not likely to exist for most > users, or check for a package. Both approaches require platform > specific code and assumptions. > > Because the traffic_ops_golang package will depend on traffic_ops, not > the other way around, it makes more sense to place the configuration > piece in the golang package. When the golang package is installed, we > can "take over" the port in the listen directive of cdn.conf, because > we know for a fact that it is on disk because of the RPM dependency on > traffic_ops. We also know that cdn.conf will be left alone if/when > traffic_ops is upgraded due to being marked as a config file. If the > user has installed either component outside of the normal RPM process, > they will have to figure out how to run the golang package separately, > as one would expect. > > We can do the configuration during the postinstall step of the > traffic_ops_golang RPM. It's advantageous to manage that piece within > the RPM, because if, for example, one wanted to remove the golang > portion, we could have a postuninstall step that reverts changes made > to cdn.conf (put the port we took over back into cdn.conf). We could > seamlessly add and remove the traffic_ops_golang component without > disturbing anything in traffic_ops, and without having to run some > script manually. The platform specific things that would need to be > done in postinstall should be done in the RPM, because then we know > for sure which platform we're on, and assumptions about packages and > paths will be accurate. > > Ideally we should be moving away from any manual run of any script > after an installation or upgrade, including postinstall, if that work > can be done within the RPM. > -- > Thanks, > Jeff > > > On Wed, Jul 19, 2017 at 9:08 AM, Robert Butts <[email protected]> > wrote: > > It sounds like the only -1 is having a unified Service and RPM. > > > > How about the following compromise: a separate RPM and Service for the > New > > TO, and the New TO RPM is a dependency of Old TO, and likewise the > Service > > is a dependency of `traffic_ops`. This way, upgrades will still require > > building the New TO RPM and adding it to Yum, but `yum upgrade` will > > automatically install it without additional ops work, and `service > > traffic_ops start` will also start the New TO. Bearing in mind this > > double-service awkwardness will go away when all endpoints are migrated. > > > > Also, @alficles suggested configuring the New TO Config in Postinstall > > (which must be run after upgrading anyway). Because the New is a > dependency > > of the Old, we're guaranteed `/opt/traffic_ops_golang` exists in > > Postinstall, and can populate its config. > > > > Also, I realized the New TO needs moved from > > `/traffic_ops/traffic_ops_golang` to `/traffic_ops_golang`, because > > `build_all.sh` requires projects be in the root directory. > > > > Also, I will add tests, docs, and configurable logging before the PR is > > merged. (Just wanted to wait until we had consensus before putting more > work > > into it.) > > > > How does that sound? > > > > > > On Thu, Jul 13, 2017 at 1:00 PM, Robert Butts <[email protected]> > > wrote: > >> > >> @dewrich It's not that putting both services in the same Service and RPM > >> is a good long-term solution; it's that it's easier to configure and > deploy. > >> A separate RPM and service is another step to install, and another step > to > >> start the service. It's not that it's good, it's that it's the lesser > of two > >> evils. My fear is, the more complex we make this, the less chance of > getting > >> it done at all. > >> > >> @efriedri > >> 1. Same answer: long-term, I absolutely agree proxies should be > separate. > >> But this is the simplest way to deploy an incremental migration. > >> 2. Yes, the Perl GUI can transparently request what it needs. That's a > >> goal of this: transparent new endpoints, that existing services don't > know > >> or care that they come from a different backend. > >> > >> Also bear in mind, this "proxy" only exists until Perl TO goes away. > >> Having it in the same Service and RPM as old TO, and having the proxy > be the > >> same binary as the new endpoints, makes it easier to completely remove > the > >> Proxy and Perl, once every endpoint is rewritten. If we make the > Service and > >> RPM separate, you have to change configs and uninstall the separate > Service > >> and RPM of the Perl TO. If the Proxy is a separate binary, you have to > >> uninstall that, and then change the config of the Golang TO to serve on > the > >> real port (443). As proposed, once all endpoints are rewritten, we > simply > >> remove the old TO from the RPM and Service, and users just upgrade, and > it > >> keeps working, with no changes to config, Puppet, RPM, or anything else. > >> > >> I'd fully support different RPMs, different Services, and a separate > >> Proxy, once this is deployed. The fear is that the more complex we make > >> this, the less chance it gets deployed at all. > >> > >> > >> On Thu, Jul 13, 2017 at 12:23 PM, Eric Friedrich (efriedri) > >> <[email protected]> wrote: > >>> > >>> Rob- > >>> Two minor questions: > >>> > >>> 1) An alternative approach could have been using an LB/proxy to choose > >>> between perl and golang TO’s. Any particular reason you chose to proxy > >>> requests to the perl TO instead? > >>> > >>> 2) As APIs are rebuilt in golang which effect GUI components, what does > >>> this mean for the perl GUI? Will we continue updating the perl GUI to > >>> interact with updated golang APIs? (until we cut over to Jeremy’s > Angular > >>> UI) > >>> > >>> —Eric > >>> > >>> > >>> > >>> > On Jul 13, 2017, at 12:39 PM, Eric Covener <[email protected]> > wrote: > >>> > > >>> > On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts > >>> > <[email protected]> wrote: > >>> >> A Golang application which serves endpoints which have been > rewritten, > >>> >> and > >>> >> reverse-proxies the old Perl Traffic Ops for all other requests. > This > >>> >> app > >>> >> can be included in the RPM and Service files for Traffic Ops. Then, > >>> >> the old > >>> >> Traffic Ops config can be changed to a different port (say, 60443), > >>> >> and the > >>> >> new Go Traffic Ops can be configured to serve on 443, and > >>> >> reverse-proxy to > >>> >> the old application. Both applications will run on the same machine. > >>> > > >>> > > >>> > Sounds neat and you didn't resort to saying "microservices"! > >>> > > >>> > -- > >>> > Eric Covener > >>> > [email protected] > >>> > >> > > >
