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://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://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://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://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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
