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)" <[email protected]> wrote: 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/6/19, 3:12 PM, "ocket 8888" <[email protected]> wrote: 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 <[email protected]> wrote: > @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 > strings together to make a function name to call, and it would be > impossible to find in the code. So, there was a fear we could break things, > and there's no way to be sure. The counterargument being: the old, wrong > code would break things worse if it were ever called. > > Thread is here: > > https://lists.apache.org/thread.html/12cad3baa9af9f92e47772f3cd7be22514ddc899d5ba18f9e35d5e1c@%3Cdev.trafficcontrol.apache.org%3E > > Nobody ever did it, but it shouldn't be hard to do. That said, there's > nothing preventing us from voting again, if we think the consensus will be > different now. > > I'm personally +1 on just deleting the routes and functions, if we're > re-voting on it. > > > On Tue, Aug 6, 2019 at 1:19 PM Henderson, Daisy < > [email protected]> > wrote: > > > 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, "Robert Butts" <[email protected]> wrote: > > > > >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 aren't under /api, they don't fall under the API promise, but > > they > > do fall under the project "deprecate-and-remove" "one major version" > > promise. I _think_ we declared all non-API versions deprecated a long > > time > > ago, but I'm not positive. We should probably declare it again, just > > to be > > sure. Either on the list, or with comments in the code, or both. If > we > > can > > find that declaration, that would be great, then we can remove them > in > > 4.0. > > > > Then, if they aren't used inside TC, they can just be removed. If > they > > are, > > we'll need to rewrite them under /api, and change whatever scripts or > > apps > > are using them. I already did this for some, several some months ago, > > but > > I'm not sure if I got all of them. It's hard to be certain. We should > > both > > search the code for anything calling them, and check our production > TO > > access logs. > > > > > > On Tue, Aug 6, 2019 at 8:29 AM ocket 8888 <[email protected]> > wrote: > > > > > 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 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? > > > > > > On Tue, Aug 6, 2019 at 8:26 AM Robert Butts <[email protected]> > wrote: > > > > > > > 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 configs. It's a lot of endpoints, but not all of them. If you > > want a > > > > list of all of them, you'll have to compare TrafficOpsRoutes.pm > and > > > > routes.go. > > > > > > > > Also be aware, for the rewrite, there may be several non-API > > routes which > > > > are still used by Traffic Control, and will have to be rewritten > > as new > > > > /api endpoints before Perl can be removed. > > > > > > > > > > > > On Tue, Aug 6, 2019 at 8:15 AM ocket 8888 <[email protected]> > > wrote: > > > > > > > > > Yeah, that's the plan > > > > > > > > > > On Tue, Aug 6, 2019 at 8:08 AM Jeremy Mitchell < > > [email protected]> > > > > > 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://protect2.fireeye.com/url?k=e1de0ea2-bd3a0069-e1de2916-000babff3540-b55aca537864275e&u=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, 2019 at 7:11 AM ocket 8888 < > [email protected] > > > > > > wrote: > > > > > > > > > > > > > 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 < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > I think the `TO API Golang Rewrite` actually makes > perfect > > sense > > > > as a > > > > > > > > milestone. It will truly be "milestone" when we finish > > that. I'm > > > > good > > > > > > if > > > > > > > > others are (or are not opposed). > > > > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 3:58 PM ocket8888 < > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > Huh. That's new. btw, I don't think you can send images > > through > > > > the > > > > > > > > > mailing list > > > > > > > > > > > > > > > > > > I still think a project is overkill, as it depends on > > assigning > > > > > > things > > > > > > > > > to people, tracking things that are "In Progress" and > > whatnot. > > > It > > > > > > > > > doesn't give you anything that a milestone wouldn't. > > > > > > > > > > > > > > > > > > There's no reason a milestone must correspond to some > > release. > > > > > > > > > > > > > > > > > > On 8/5/19 3:51 PM, Jeremy Mitchell wrote: > > > > > > > > > > image.png > > > > > > > > > > looks like a project "tracks absolute progress toward > > some > > > > goal". > > > > > > > it's > > > > > > > > > > got a progress bar and everything: > > > > > > > > > > > > > https://protect2.fireeye.com/url?k=31132953-6df72798-31130ee7-000babff3540-9ff47b40213aec0f&u=https://github.com/apache/trafficcontrol/projects/2 > > > > > > > > > > > > > > > > > > > > > I wouldn't be opposed to creating a project as > well, > > but > > > I'm > > > > > > > > skeptical > > > > > > > > > > that it would be used. > > > > > > > > > > > > > > > > > > > > It would be used if you managed it and made sure it > > stayed up > > > > to > > > > > > > date. > > > > > > > > > > You can also set up projects to auto-update. When you > > create > > > > the > > > > > > > > > > project, select the type. for example: > > > > > > > > > > > > > > > > > > > > /Automated kanban > > > > > > > > > > Kanban-style board with built-in triggers to > > automatically > > > move > > > > > > > issues > > > > > > > > > > and pull requests across To do, In progress and Done > > columns. > > > > > > > > > > / > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 3:20 PM ocket8888 < > > > [email protected] > > > > > > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > > > > > > A project is a way of organizing work by keeping > > track of > > > > who > > > > > > is > > > > > > > > > > working > > > > > > > > > > on what and at what stage a particular part of > the > > > project > > > > > is. > > > > > > A > > > > > > > > > > milestone tracks absolute progress toward some > > goal, > > > which > > > > is > > > > > > all > > > > > > > > I'm > > > > > > > > > > seeking to accomplish. > > > > > > > > > > > > > > > > > > > > I wouldn't be opposed to creating a project as > > well, but > > > > I'm > > > > > > > > > > skeptical > > > > > > > > > > that it would be used. > > > > > > > > > > > > > > > > > > > > On 8/5/19 3:02 PM, Jeremy Mitchell wrote: > > > > > > > > > > > I've just always associated milestone with > > release for > > > > some > > > > > > > > > > reason... > > > > > > > > > > > > > > > > > > > > > > Feels like a "project" to me however. Oh look > at > > that > > > > there > > > > > > was > > > > > > > > > > one for > > > > > > > > > > > this at one time: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://protect2.fireeye.com/url?k=8449032a-d8ad0de1-8449249e-000babff3540-ab0e9732ae0e32f0&u=https://github.com/apache/trafficcontrol/projects?query=is%3Aclosed > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 2:56 PM ocket8888 < > > > > > > [email protected] > > > > > > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > > > > > > > >> As far as I know, the only thing you get with > a > > > > Milestone > > > > > > > > > > (immediately > > > > > > > > > > >> and by default) that doesn't come with a label > > is the > > > > > > ability > > > > > > > > > > to track > > > > > > > > > > >> progress towards reaching that milestone. > Which > > I > > > think > > > > is > > > > > > > > > > appropriate > > > > > > > > > > >> here - and is actually all of my motivation > for > > > > > suggesting a > > > > > > > > > > milestone > > > > > > > > > > >> rather than a label. What "baggage" do you > mean? > > > > > > > > > > >> > > > > > > > > > > >> On 8/5/19 2:52 PM, Chris Lemmons wrote: > > > > > > > > > > >>> I agree that separate tickets is ideal. Would > > a tag > > > > work > > > > > > for > > > > > > > > this > > > > > > > > > > >>> purpose? Milestones have other baggage that > > doesn't > > > > apply > > > > > > > here. > > > > > > > > > > >>> > > > > > > > > > > >>> On Mon, Aug 5, 2019 at 2:16 PM ocket 8888 < > > > > > > > [email protected] > > > > > > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > >>>> Currently to see what endpoints are > rewritten > > and > > > > which > > > > > > > still > > > > > > > > > > need to be > > > > > > > > > > >>>> done, you need to check out this one, > > specific issue > > > > Rob > > > > > > > made > > > > > > > > > > forever > > > > > > > > > > >> ago: > > > > > > > > > > >>>> > > > > > > https://protect2.fireeye.com/url?k=755603ef-29b20d24-7556245b-000babff3540-00731ec0bbe9a19e&u=https://github.com/apache/trafficcontrol/issues/2232 > > > > > > > > > > >>>> I think it'd be better to give each endpoint > > its own > > > > > > Issue - > > > > > > > > > > only the > > > > > > > > > > >> ones > > > > > > > > > > >>>> that still need to be rewritten - and then > > link them > > > > all > > > > > > in > > > > > > > a > > > > > > > > > "Go > > > > > > > > > > >> Rewrite" > > > > > > > > > > >>>> milestone. It's much easier to organize. > Then > > we can > > > > > stop > > > > > > > > > > re-building > > > > > > > > > > >> this > > > > > > > > > > >>>> list. > > > > > > > > > > >>>> I volunteer to comb through the list and > > figure out > > > > what > > > > > > > > > > endpoints > > > > > > > > > > >> actually > > > > > > > > > > >>>> are rewritten and do the work of creating > > issues for > > > > > them, > > > > > > > > > > provided > > > > > > > > > > >> that's > > > > > > > > > > >>>> acceptable to everyone? I think we typically > > only > > > use > > > > > > > > > > milestones for > > > > > > > > > > >>>> releases, so I thought I should check. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
