Open Stack

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
>