Move autoupdate code in proxy to make more sense #49484
Conversation
| @@ -1073,7 +1070,7 @@ func (h *Handler) bindDefaultEndpoints() { | |||
|
|
|||
| // Implements the agent version server. | |||
| // Channel can contain "/", hence the use of a catch-all parameter | |||
| h.GET("/webapi/automaticupgrades/channel/*request", h.WithUnauthenticatedHighLimiter(h.automaticUpgrades)) | |||
| h.GET("/webapi/automaticupgrades/channel/*request", h.WithUnauthenticatedHighLimiter(h.automaticUpgrades109)) | |||
There was a problem hiding this comment.
Can we refer to this a legacy automatic upgrades instead of referencing the RFD in code?
There was a problem hiding this comment.
I don't really like calling them legacy because some parts of the RFD109 will still be used as a fallback for RFD184, and the RFD109 APIs will soon be able to tell to update based on RFD184 configuration.
So you can have legacy updaters using legacy APIs to update according to the new schedule, and new updaters using the new API to update according to the legacy schedule.
As both systems will share a common update logic I don't see channels as legacy, just as a different API service the same content.
The interoperability logic will be introduced in #49380
There was a problem hiding this comment.
I also asked the question here: https://gravitational.slack.com/archives/C04P78M46F2/p1732304167957549
Splitting up #49380 to make it more palatable.
This PR moves code around and rename functions to reflect the difference between RFD 109 and RFD 184 autoupdates. No logic changed in this PR.
The tool autoupdate got sucked into RFD184 this as they share the same API, I did not suffix their functions with "184" though.