Re: [EXTERNAL] Re: Traffic Ops API versioning issues

[Jeremy Mitchell <mi...@gmail.com>]

+1

On Tue, Apr 30, 2019 at 1:00 PM Dave Neuman <ne...@apache.org> wrote:

> +1 to Rawlin's latest proposal.
> If we can get consensus then let's close the PRs for previous solutions and
> move forward with this one.
>
> Thanks,
> Dave
>
>
> On Fri, Apr 26, 2019 at 3:58 PM Rawlin Peters <ra...@gmail.com>
> wrote:
>
> > On Wed, Apr 24, 2019 at 10:53 AM Robert Butts <ro...@apache.org> wrote:
> > > We might even be able to do a little better than that, and only have
> one
> > > handler, no separate versions in the routes/handlers. So, the route
> would
> > > look something like:
> > >
> > > func Update(w http.ResponseWriter, r *http.Request) {
> > > inf, userErr, sysErr, errCode := api.NewInfo(r, nil, nil)
> > > dsVer := tc.NewDeliveryService(inf.Version)
> > > api.Parse(r.Body, inf.Tx.Tx, &ds)
> > > ds := dsVer.Upgrade(inf.Tx.Tx)
> >
> > I think that could be doable, but I think that would imply having to
> > go update every minor-versioned-struct's `Upgrade` method whenever a
> > new minor version is added. That is, each minor-versioned-struct would
> > need to maintain instructions on how to upgrade to the latest version
> > of the struct. That maintenance cost would increase with every added
> > minor version, which is why I was thinking it should really just chain
> > together, upgrading/downgrading the request. That way when adding a
> > new minor version, you'd only be on the hook for writing instructions
> > to upgrade from the previous minor version to the latest minor
> > version, without having to touch any of the other minor versions. The
> > less we have to touch the previous minor versions, the easier it would
> > be for us to support _all_ minor versions, which means TO clients
> > would last longer without needing to upgrade (as opposed to just
> > supporting the "latest" minor version of the API and dropping all
> > other minor versions from one major TC release to the next, like
> > Jonathan has described).
> >
> > A downside to chaining would be that each minor version upgrade you
> > have to do is an extra DB query, so if a client is on the oldest
> > possible minor version, they could be taking a decent hit on added
> > latency. But, if it becomes a problem for the client, they would have
> > added incentive to upgrade to the latest minor version. If we drop
> > support for all but the latest minor version of the API when we
> > upgrade to the next major TC version, I think that would mean we'd
> > really only be supporting two minor versions at any point in time, so
> > maybe doing it the way you've proposed in the code snippet above would
> > be the same amount of work at that point anyways.
> >
> > - Rawlin
> >
>

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

[Rawlin Peters <ra...@gmail.com>]

For anyone interested in what the resulting code would look like for
my TO API minor versioning proposal, I prototyped a new `foos`
endpoint that supports several different minor versions (as if the
endpoint had seen minor changes across several different releases of
Traffic Control -- not that we would ever add a new endpoint
supporting multiple minor versions at once):

https://github.com/apache/trafficcontrol/pull/3538

My plan is to refactor the current Delivery Services API
implementation into something very close to that in order to simplify
the handling of minor versioning. After delivery services, I might
tackle the one or two other endpoints that also do minor versioning in
order to be consistent with this approach.

- Rawlin

On Tue, Apr 30, 2019 at 7:55 PM Jeremy Mitchell <mi...@gmail.com> wrote:
>
> +1
>
> On Tue, Apr 30, 2019 at 1:00 PM Dave Neuman <ne...@apache.org> wrote:
>
> > +1 to Rawlin's latest proposal.
> > If we can get consensus then let's close the PRs for previous solutions and
> > move forward with this one.
> >
> > Thanks,
> > Dave
> >
> >
> > On Fri, Apr 26, 2019 at 3:58 PM Rawlin Peters <ra...@gmail.com>
> > wrote:
> >
> > > On Wed, Apr 24, 2019 at 10:53 AM Robert Butts <ro...@apache.org> wrote:
> > > > We might even be able to do a little better than that, and only have
> > one
> > > > handler, no separate versions in the routes/handlers. So, the route
> > would
> > > > look something like:
> > > >
> > > > func Update(w http.ResponseWriter, r *http.Request) {
> > > > inf, userErr, sysErr, errCode := api.NewInfo(r, nil, nil)
> > > > dsVer := tc.NewDeliveryService(inf.Version)
> > > > api.Parse(r.Body, inf.Tx.Tx, &ds)
> > > > ds := dsVer.Upgrade(inf.Tx.Tx)
> > >
> > > I think that could be doable, but I think that would imply having to
> > > go update every minor-versioned-struct's `Upgrade` method whenever a
> > > new minor version is added. That is, each minor-versioned-struct would
> > > need to maintain instructions on how to upgrade to the latest version
> > > of the struct. That maintenance cost would increase with every added
> > > minor version, which is why I was thinking it should really just chain
> > > together, upgrading/downgrading the request. That way when adding a
> > > new minor version, you'd only be on the hook for writing instructions
> > > to upgrade from the previous minor version to the latest minor
> > > version, without having to touch any of the other minor versions. The
> > > less we have to touch the previous minor versions, the easier it would
> > > be for us to support _all_ minor versions, which means TO clients
> > > would last longer without needing to upgrade (as opposed to just
> > > supporting the "latest" minor version of the API and dropping all
> > > other minor versions from one major TC release to the next, like
> > > Jonathan has described).
> > >
> > > A downside to chaining would be that each minor version upgrade you
> > > have to do is an extra DB query, so if a client is on the oldest
> > > possible minor version, they could be taking a decent hit on added
> > > latency. But, if it becomes a problem for the client, they would have
> > > added incentive to upgrade to the latest minor version. If we drop
> > > support for all but the latest minor version of the API when we
> > > upgrade to the next major TC version, I think that would mean we'd
> > > really only be supporting two minor versions at any point in time, so
> > > maybe doing it the way you've proposed in the code snippet above would
> > > be the same amount of work at that point anyways.
> > >
> > > - Rawlin
> > >
> >