I am also +1 on this. I think should get the Golang "legos" in place (authentication, capabilities, tenancy), then chip away at the old functionality while gaining a short term wins. I like the idea of building a service that implements MojoCookie+Capabilities which will allow us to use the new API capabilities with existing TrafficOps Routes and evolve the application forward (not just a Perl to Golang port). Rebuild the hot endpoints as necessary then before you know it, Perl gets shelved.
But, I'm -1 on packaging this into the already bloated TrafficOps (Perl) rpm. I think we should design a new lean Golang based project that gets rolled into a "sidecar" style rpm that can be scaled and deployed in a more strategic fashion. - Dew On Thu, Jul 13, 2017 at 9:59 AM, Robert Butts <[email protected]> wrote: > > ---------- Forwarded message ---------- > From: Durfey, Ryan <[email protected]> > Date: Thu, Jul 13, 2017 at 9:26 AM > Subject: Re: Traffic Ops Golang Migration Proposal > To: "[email protected]" < > [email protected]> > > > I am +1 on this. We are actively discussing how config management should > work as we move forward and think a rewrite gives us a better opportunity > to overhaul how it works. > > > > Also, should this go to [email protected] vs. users? > > > > *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099> > > CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or > [email protected] > > > > > > *From: *Jason Tucker <[email protected]> > *Reply-To: *"[email protected]" < > [email protected]>, "[email protected]" < > [email protected]> > *Date: *Thursday, July 13, 2017 at 9:18 AM > *To: *"[email protected]" < > [email protected]> > *Subject: *Re: Traffic Ops Golang Migration Proposal > > > > While I have sentimental attachments to perl, I'm +1 on moving to a > non-perl alternative. From an administrator's perspective, anything that > helps me avoid perl module dependency tangles is a win. > > __Jason > > > > On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts <[email protected]> > wrote: > > I'd like to propose a plan for rewriting Traffic Ops in Golang. > > It's been a goal of Traffic Control for years now to rewrite the aging > Perl Traffic Ops app. We've made numerous prototypes and attempts, none of > which have made it past the prototype stage. > > See > https://github.com/apache/incubator-trafficcontrol/tree/master/traffic_ops/goto > > https://github.com/apache/incubator-trafficcontrol/tree/mast > er/traffic_ops/experimental/server > https://github.com/apache/incubator-trafficcontrol/tree/mast > er/traffic_ops/experimental/postgrest > https://github.com/apache/incubator-trafficcontrol/tree/mast > er/traffic_ops/experimental/traffic_ops_auth > https://github.com/apache/incubator-trafficcontrol/tree/mast > er/traffic_ops/experimental/url-rewriter-nginx > https://github.com/apache/incubator-trafficcontrol/tree/mast > er/traffic_ops/experimental/go-monitoring > > I believe this is primarily because (1) Traffic Ops is too large to > rewrite all at once, and (2) Traffic Ops requires considerable operations > tooling (RPMs, Config files [Puppet/Ansible/etc], Postinstall, etc), and > none of the prototypes were operationally simple or complete. > > To this end, I asked the question, "What is the operationally simplest > application we can create, which enables incrementally rewriting Traffic > Ops?" This is the answer I came up with: > > 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. > > The new app will accept, understand, and authenticate Mojolicious cookies > the same way the old Perl TO does, including refreshing cookies with a new > expiration in the reply. > > > > In this way, the new TO can be deployed trivially, only requiring a > one-line config change in the old TO, and a single new config file for the > new TO (e.g. in Puppet). > > > > Then, API endpoints can be rewritten one-by-one, until the new TO has all > endpoints and the old Perl TO can simply be removed. > > Note this does NOT replace or affect the "API Gateway" plans, or "JWT > Auth" plans. This is a rewrite of strictly the existing Traffic Ops > application, and can be implemented alongside the "API Gateway", or "JWT > Auth", or without them. > > > > Everything I just proposed is already written, including the Auth, RPM, > and Service. Initially, it serves > `/api/1.2/cdns/{cdn}/configs/monitoring.json` > and proxies everything else. The PR is at > https://github.com/apache/incubator-trafficcontrol/pull/729 > > > > I believe this to be the simplest, easiest, fastest, and cheapest way to > rewrite Traffic Ops, and likely the only way we will accomplish rewriting > the massive Perl application. > > > > Thoughts? > > > >
