---------- Forwarded message ---------- From: Durfey, Ryan <ryan_dur...@comcast.com> Date: Thu, Jul 13, 2017 at 9:26 AM Subject: Re: Traffic Ops Golang Migration Proposal To: "us...@trafficcontrol.incubator.apache.org" < us...@trafficcontrol.incubator.apache.org>
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 dev@trafficcontrol.incubator.apache.org vs. users? *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or cdn_supp...@comcast.com *From: *Jason Tucker <jasonwtuc...@gmail.com> *Reply-To: *"us...@trafficcontrol.incubator.apache.org" < us...@trafficcontrol.incubator.apache.org>, "jasonwtuc...@gmail.com" < jasonwtuc...@gmail.com> *Date: *Thursday, July 13, 2017 at 9:18 AM *To: *"us...@trafficcontrol.incubator.apache.org" <users@trafficcontrol. incubator.apache.org> *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 <robert.o.bu...@gmail.com> 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/master/traffic_ops/experimental/server https://github.com/apache/incubator-trafficcontrol/tree/master/traffic_ops/experimental/postgrest https://github.com/apache/incubator-trafficcontrol/tree/master/traffic_ops/experimental/traffic_ops_auth https://github.com/apache/incubator-trafficcontrol/tree/master/traffic_ops/ experimental/url-rewriter-nginx https://github.com/apache/incubator-trafficcontrol/tree/master/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?
