-
-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API::delete behavior and idempotency #1107
Comments
Hm, yeah, you do raise a good point here, and I think what we have is slightly different than what is intended by the upstream api. While it is more in-line with rust to return actual
IIRC you need to fiddle with the I think there is room to experiment here with a more idempotent Feel free to sketch out a PR for ideas on this, and I can review, otherwise i'll leave it as help wanted. |
We faced a similar problem internally and we got around it by doing this. I hope this helps anybody else looking for a similar solution as well: #[async_trait]
pub trait DeleteOpt<T> {
async fn delete_opt(
&self,
name: &str,
dp: &DeleteParams,
) -> Result<Option<Either<T, Status>>>;
}
#[async_trait]
impl<T> DeleteOpt<T> for Api<T>
where
T: Clone + DeserializeOwned + Debug,
{
async fn delete_opt(
&self,
name: &str,
dp: &DeleteParams,
) -> Result<Option<Either<T, Status>>> {
match self.delete(name, dp).await {
Ok(obj) => Ok(Some(obj)),
Err(Error::Api(ErrorResponse { code: 404, .. })) => Ok(None),
Err(err) => Err(err),
}
}
} We then use this by simply doing: Api::<Service>::namespaced(kubernetes_client, namespace)
.delete_opt(
&service_name,
&DeleteParams::default(),
)
.await?; |
Would you like to work on this feature?
None
What problem are you trying to solve?
I'm trying to delete a kubernetes object using
Api::delete
Describe the solution you'd like
When deleting the object, for my use-case I would like to know if
My understanding of Api::delete was that I would use
Ok(Either::Left)
to determine deletion is ongoing,Ok(Either::Right)
to determine it's completed, and that all errors (Err
) are of a more general nature.However once testing this, I noticed that trying to delete an already deleted object yields an
Err
. This makes sense according to the documentationBut I don't think it's a natural mapping to the
delete
semantics, which should be idempotent.I would have expected a deletion attempt on an object that is not available (
404
) to be returned viaOk(Either::Right)
, which is the same as deleting that is immediately gone. In both cases the result for the caller is that we are sure the object is no longer there.The current setup requires to special case
Err(kube::Error::Api(api_error)) if api_error.code == 404
on the caller side and treat it the same asOk(Either::Right)
if one wants to achieve idempotent deletion. In fact in my setup I wasn't even able to observe anOk(Either::Right)
- deletion directly went fromOk(Either::Left)
to a 404 error - which I initially not anticipated due to the API description.I obviously realize a change in behavior would be a breaking change, and that automatically trying to treat 404s and 200 results the same might be a loss of information for some applications, so there's obviously a drawback too.
An other related question I had is what inspection users are expected to be able to perform with a
Either::Right
, if they just want know that the object is gone. The documentation mentions potentially different status2xx
status codes, but I couldn't find any references in kubernetes docs on whether something else than a200
status would be expected and what the meaning of other codes is. If someone has a description, it might be helpful to add this to theApi::delete
docs.Describe alternatives you've considered
Manually special casing the 404 error - as described above
Documentation, Adoption, Migration Strategy
No response
Target crate for feature
No response
The text was updated successfully, but these errors were encountered: