Thanks for the clear explanation Brian. Based on what you described + Dan's comment, this sounds logical as an exception to the policy and be backported to stable/yoga. It's good that this was cought in this fairly early phase. :) Előd (irc: elodilles) On 2022. 05. 20. 0:05, Dan Smith wrote:
We recently noticed that an Image API call implemented in Yoga, which returns no content, is returning a 200 instead of a 202 (as the design [0] had specified). We would like to correct this in master (Zed development) and in the stable/yoga branch. Here are our reasons why we think this is a legitimate exception to the no-http-api-changes-backport policy:
(1) Even ignoring the lack of a response body, a 200 (OK) is misleading because operation initiated by the PUT /v2/cache/{image_id} request may not succeed. A 202 (Accepted) signals more clearly to the operator that some followup is necessary to be sure the image has been cached. ...may not succeed, will be processed in the background, and may never actually happen. In other words, the textbook definition of 202 :)
(2) This is intended as an admin-only API call; the default policy is admin-only. So it has not been exposed to end-users.
(3) The change [1] was first released in Yoga and there has not been much time for admins to begin consuming this feature. Further, there has not yet been a release from stable/yoga after glance 24.0.0.
For these reasons, we request that the glance team be allowed to make this change. Yep, my feeling is that we caught this very early and that it's a very limited-scope operation which means the number of people potentially impacted is very small. It's unlikely many people are yet running Yoga in production, and of those, only some admins and scripts could be affected, and only those that were super excited to use this brand new rather minor feature right away. It's an API for a function that was already being handled by a different tool, so people would have had to *convert* their existing stuff to this already, which is even less likely than some new exciting functionality that didn't exist before.
I think the calculus comes down to:
If we do backport it, a small number of super bleeding-edge admins *may* have already jumped on writing against this API and may notice. The vast majority of people that end up deploying Yoga will never experience pain.
If we don't backport it, we'll ensure that many more people will be affected. People _will_ eventually deploy Yoga, and then they _will_ deploy Zed. Those people _will_ experience a change, and I think it's clear that this class of people is larger than the one described above.
It sucks, but I think it's less pain overall to backport ASAP, reno the mea culpa clearly, and limit the number of affected people to the much smaller number.
--Dan