@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] > >
