The attachment didn't send; here's a pastebin of the same output: https://pastebin.com/Lj1cH4p6.
- Rawlin On Mon, Jul 2, 2018 at 9:06 AM Rawlin Peters <rawlin.pet...@gmail.com> wrote: > > I just discovered that there are a handful of Perl TO UI pages that > also depend on Perl API endpoints (screenshot attached). So, I think > we should either: > 1. Fix the Perl TO UI pages to make requests to traffic_ops_golang > (just changing the URL from /api/1.1/cachegroups.json to > http://localhost:<traffic_ops_golang port>/api/1.1/cachegroups.json > doesn't work; TO golang gives the error "error getting cookie: http: > named cookie not present") > 2. Remove these Perl TO UI pages that have a direct equivalent in > Traffic Portal (which properly makes requests to traffic_ops_golang) > 3. Accept that obsolete Perl UI pages can be "broken" (since they're > dependent upon Perl endpoints that have been rewritten in Go) and > display a warning on the Perl UI page > > My vote would be for option 2 because option 1 would be wasted effort > long-term, and it should be very easy to verify that TP has all the > same functionality as the TO UI equivalent before removing a page. I > know we're really close to getting TP parity and have discussed > removing the entire Perl UI after a major release or two, but I think > we can reap some immediate benefits by removing obsolete TO UI pages > that have a direct equivalent in TP now (at least the ones in the > attached screenshot) without having to delete the entire TO UI. For > instance, if an endpoint has already been rewritten in > traffic_ops_golang, you wouldn't have to update both implementations > of the API just to keep the old Perl UI intact. > > Maybe we could even replace the obsolete pages with a configurable > link to the TP equivalent. We'd get the benefit of having more users > migrate to TP who could help find gaps in parity. We'd also somewhat > alleviate the issue of PRs implementing new features in Perl rather > than Go and TP. > > Does anyone see any problems with this option (2)? > > - Rawlin > > On Tue, Jun 26, 2018 at 9:48 AM Dewayne Richardson <dewr...@apache.org> wrote: > > > > At this point, I think the Perl tests have rotted so much and I don't want > > to put anymore effort into them. I say as long as we have Go coverage > > (because the API tests will still go through to Perl if no Go catches the > > route), then I'm good. > > > > -Dew > > > > On Tue, Jun 26, 2018 at 8:14 AM Robert Butts <r...@apache.org> wrote: > > > > > I had planned on deleting tests for deleted functions (which have tests in > > > Go), and starting with functions whose tests aren't depended on by any > > > other tests, and working our way up. Unless anyone objects. > > > > > > > > > On Mon, Jun 25, 2018 at 8:17 AM, Rawlin Peters <rawlin.pet...@gmail.com> > > > wrote: > > > > > > > Alright, so we have a compromise on the dead Perl API code, but what > > > > about the Perl tests that use the routed functions we're changing to > > > > just return an error? We can remove the Perl tests that test the dead > > > > endpoints, but what about any live Perl endpoints that depend on dead > > > > ones? > > > > Move the Perl API code into a new test-only function and call that > > > > from the test? > > > > Just delete the test because it depends on a dead endpoint? > > > > Delete and rewrite it in the Go testing framework? > > > > > > > > - Rawlin > > > > > > > > On Sun, Jun 24, 2018 at 1:45 PM, Dan Kirkwood <dang...@gmail.com> wrote: > > > > > On Sat, Jun 23, 2018 at 10:05 AM Robert Butts <r...@apache.org> wrote: > > > > > > > > > >> >as long as we have 100% feature complete with the Go code (which I > > > > think > > > > >> we're fairly close?) > > > > >> We are not close. We are at 108 of 240 endpoints. > > > > >> > > > > >> >if we do not treat the tests as first class citizens (meaning we > > > > implement > > > > >> an Go endpoint and build coverage as we go), then why bother at all? > > > > >> It doesn't have to be all or nothing. There's a happy medium between > > > > >> requiring tests for every line of code, and having no tests. > > > > >> > > > > >> >I also thought that we were supporting removing the Perl in the next > > > TC > > > > >> 3.0 major release (several emails back). > > > > >> That vote was to remove the Perl GUI, not all of Perl. > > > > >> > > > > >> > > > > >> >Removing dead Perl code can be tricky, since the interdependencies > > > are > > > > >> not always obvious, and can lead to unforeseen missing functionality. > > > > >> > > > > >> That's a good point. But let me ask this: in the event we miss some > > > > dynamic > > > > >> Perl calling a function that was removed, which is worse: to make > > > > >> that > > > > >> function fail, or to make that function call dead code, which has > > > > >> been > > > > >> changed and modified to behave differently in Go, and the undead Perl > > > is > > > > >> now doing the wrong thing? > > > > >> > > > > > > > > > > In the case where a function is removed that overrode some default > > > > > functionality (which happens a lot in this code), the default code > > > would > > > > > not fail, but produce different results. Not quite helpful.. > > > However, > > > > > the idea you present below mitigates that risk.. > > > > > > > > > > > > > > >> So, there might be a middle ground. How about this: what if we remove > > > > the > > > > >> Perl routes from the routes file, and change the functions to > > > > immediately > > > > >> return an informative error message? That way, if we miss some > > > > >> dynamic > > > > Perl > > > > >> still calling the code, we immediately get a useful message, so it's > > > > easy > > > > >> to find and fix. And we don't call old, wrong code that could do > > > > something > > > > >> dangerous and bad. And additionally, contributors in the community > > > won't > > > > >> see the functions that look real, and accidentally waste their time > > > > >> modifying them. > > > > >> > > > > > > > > > > This, I can live with, and I think it represents a good way > > > > > forward: > > > > > keep the signature of all functions -- do not remove any modules and > > > > > replace the guts of each of those functions with a sensible error -- > > > even > > > > > with a stack trace so we can tell exactly what code path was used to > > > get > > > > > there. It should be fairly straightforward to create a utility > > > function > > > > > that can be used throughout so it happens consistently. > > > > > > > > > > > > > > > > > > > >> Those who voted against removing the dead code, does that sound like > > > > >> a > > > > >> compromise you could live with? > > > > > > > > > > > > > > > That's a yes from me. Thanks for coming up with a solid compromise.. > > > > > > > > > > -Dan > > > > > > > > > > > > > > >> On Thu, Jun 21, 2018 at 7:52 AM, Dewayne Richardson < > > > dewr...@apache.org > > > > > > > > > >> wrote: > > > > >> > > > > >> > I'm +100 on removing dead Perl code as long as we have 100% feature > > > > >> > complete with the Go code (which I think we're fairly close?). > > > Rawlin > > > > >> you > > > > >> > are correct in that there is a spider web of interdependencies in > > > > Perl, > > > > >> but > > > > >> > without feature parity removing any of that dead code is like > > > pulling > > > > a > > > > >> > single thread from a sweater without unraveling the entire thing. > > > In > > > > >> other > > > > >> > words let's put our efforts around Go features and moving forward. > > > > >> > > > > > >> > As for tests, I realize writing tests "takes time", but we have to > > > > build > > > > >> a > > > > >> > safety net for the Traffic Ops Go API's going forward. I also > > > realize > > > > >> that > > > > >> > writing and maintaining the API tests is like maintaining two code > > > > bases, > > > > >> > but if we do not treat the tests as first class citizens (meaning > > > > >> > we > > > > >> > implement an Go endpoint and build coverage as we go), then why > > > > bother at > > > > >> > all? I'm pretty sure there is support for more testing and I also > > > > think > > > > >> it > > > > >> > has to be a "community" effort. > > > > >> > > > > > >> > I also thought that we were supporting removing the Perl in the > > > > >> > next > > > > TC > > > > >> 3.0 > > > > >> > major release (several emails back). > > > > >> > > > > > >> > -Dew > > > > >> > > > > > >> > On Wed, Jun 20, 2018 at 9:54 AM Rawlin Peters < > > > > rawlin.pet...@gmail.com> > > > > >> > wrote: > > > > >> > > > > > >> > > Hey Traffic Controllers, > > > > >> > > > > > > >> > > In order to accelerate our progress toward using and developing > > > > >> > > traffic_ops_golang as a community, I'd like to propose that we > > > > remove > > > > >> > > all of the dead Perl Traffic Ops API code in the repo. Many > > > > endpoints > > > > >> > > have been rewritten in Go at this point, and by keeping the > > > obsolete > > > > >> > > Perl endpoints in the repo we're not making it clear that new > > > > >> > > enhancements have to be made in traffic_ops_golang and Traffic > > > > Portal > > > > >> > > in order to actually work and survive long-term (as opposed to > > > > >> > > the > > > > >> > > legacy Perl Traffic Ops API and UI which is planned to be > > > deprecated > > > > >> > > and removed in the near future). > > > > >> > > > > > > >> > > Right now the only thing keeping the dead Perl endpoints from > > > being > > > > >> > > deleted is the Perl test framework that depends on them. > > > > Unfortunately > > > > >> > > the tests are all caught in a spider web of interdependency, so > > > > >> > > we > > > > >> > > can't simply remove tests for APIs that have been rewritten in Go > > > > >> > > without breaking other tests. However, we think there are a few > > > ways > > > > >> > > we should be able to accomplish this: > > > > >> > > > > > > >> > > 1. Make the Perl integration tests actually make HTTP calls which > > > > can > > > > >> > > then be handled by traffic_ops_golang, rather than calling the > > > Perl > > > > >> > > API router directly. > > > > >> > > 2. Remove test interdependencies by mocking out the test data. > > > > >> > > 3. Rewrite all the Perl tests in the go API test framework and > > > > remove > > > > >> > > the Perl tests. > > > > >> > > > > > > >> > > We are also open to other suggestions that allow us to remove > > > > >> > > dead > > > > Perl > > > > >> > > code :). > > > > >> > > > > > > >> > > Please +1 or -1 if you agree or disagree; all feedback is > > > > >> > > welcome. > > > > >> > > > > > > >> > > - Rawlin > > > > >> > > > > > > >> > > > > > >> > > > > > > >
