It seems you have a very specific set of goals with this proposal rather than a general practice here, and possibly a very limited duration for this proposal. While yes you’ve thought through t3c in this case and it might be ok if everything works as it should, the general objection is still true. It’s not possible to know all API consumer behavior. This is why API versioning practices are so critically important in addition to supported upgrade practices. My objection stands, but as the implementor and with the additional +1 you have, you’re welcome to ignore and proceed anyway.
Jonathan G From: Rawlin Peters <raw...@apache.org> Date: Wednesday, September 8, 2021 at 9:39 AM To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> Subject: Re: [EXTERNAL] Proposal: stable vs unstable TO API versions I understand your point, Jonathan and Rob, but I think it is a bit much to assume that every upgrade of components that use the unstable API will break them entirely and cause a customer impact/outage. For the 3 things we're planning on breaking (jobs, users, servers), I'm pretty sure `t3c` is the only component truly affected that could potentially create bad ATS configs. Let's look at each in turn: Jobs: If TO is upgraded first, `t3c` requests will get a 200, but it will just ignore the new field returned in the JSON, meaning jobs will still be "refresh" instead of "refetch." No impact here. If `t3c` is upgraded first, the new field will be empty, meaning `t3c` should just treat it as "refresh." No impact here either. Users: `t3c` does not use this API and will not be impacted. Servers: If TO is upgraded first, `t3c` requests will get a 200, but it will think all server profile IDs = 0 (because the field will be missing from the response, it will get unmarshalled as the int's "empty" value). `t3c` will then attempt to get parameters of profile 0 and get 404'd, causing the run to fail, leaving old configs in place. No real impact here other than not being able to change ATS configs until `t3c` is upgraded. If `t3c` is upgraded first, `t3c` requests will get a 200, but since the resulting profile arrays would be empty, it will cause the `t3c` run to fail, leaving old configs in place. Again, no real impact other than not being able to change ATS configs until TO is also upgraded. As you can see, this single coordinated upgrade would not cause any real impact. Would you at least be willing to try it out for the next release cycle in order to get these 3 breaking changes into API 4.0? That alone would be a major savings, and we'd only have to coordinate a single upgrade. - Rawlin
