I agree with Andy on the 'return an error message' for now, and comment out the
already ported Perl endpoints. Is there any issue with simply commenting them
out for now?
-Daisy
On 8/6/19, 3:20 PM, "Schmidt, Andrew (Contractor)"
wrote:
In that case I would vote for the conclusion of the
In that case I would vote for the conclusion of the original discussion,
'return an error message'. I think it's important to get a release out that
actually has perl endpoints disabled so we can find out if any of our users are
accessing them directly. Clingy legacy code is the worst.
On 8/
We don't need to delete it, just commenting out the route for the moment
would be enough imo.
The Perl libraries could be calling into each other, so deleting them is
unsafe, in general.
On Tue, Aug 6, 2019 at 1:34 PM Robert Butts wrote:
> @Daisy_Henderson We had a discussion on it, and the cons
@Daisy_Henderson We had a discussion on it, and the consensus was to leave
the route functions in place, and change the functions they call to
immediately return an error, "This endpoint should not have been possible
to call."
TLDR, the reason is because Perl is so dynamic, you could concatenate
s
Chiming in here. For the Perl API routes that have already been rewritten in
Go, can we comment those out in the 'TrafficOpsRoutes.pm' file? It would help
organize the non-ported endpoints and make it more visible as to which Perl
endpoints are still being used.
-Daisy
On 8/6/19, 8:46 AM, "Ro
>There definitely are some that are still defined and not commented-out in
the Perl routes file. I haven't really thought about what to do with those
- maybe I'll just open an issue for each that says something like "Decide
what to do about {{route}}" and then deal with it later. Thoughts?
If they
Yeah, I'll need to do some digging to find an exhaustive list, but yours is
a good starting point.
> There may be several non-API routes which are still used by Traffic
Control
There definitely are some that are still defined and not commented-out in
the Perl routes file. I haven't really thought
Just to check, you all know this isn't a list of all endpoints in Traffic
Ops, right? As the issue says, "all tables queried for the CRConfig."
That list, which really existed for my own use for Self Service, is only
the endpoints which query tables used in the CRConfig, and not including
ATS conf
Yeah, that's the plan
On Tue, Aug 6, 2019 at 8:08 AM Jeremy Mitchell
wrote:
> Just so we're clear on what your asking. You want to create a github issue
> for each unchecked item in this issue, right?
> https://github.com/apache/trafficcontrol/issues/2232
>
> Then what? close 2232? Each endpoint
Just so we're clear on what your asking. You want to create a github issue
for each unchecked item in this issue, right?
https://github.com/apache/trafficcontrol/issues/2232
Then what? close 2232? Each endpoint can be tackled individually so that
seems to make sense to me.
Jeremy
On Tue, Aug 6
So it seems that at least we can all agree these should have their own
issues, so far. I'll leave the question of label/milestone/project
unanswered for now and just start opening issues.
On Mon, Aug 5, 2019 at 7:49 PM Jeremy Mitchell
wrote:
> I think the `TO API Golang Rewrite` actually makes p
11 matches
Mail list logo
