This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/sig docs
/language en

Hi @rahul38888,
There is a step mentioned to ensure the service is deleted before verifying with the curl command.

Confirm that the Service is gone:
kubectl get services

Is this not sufficient? Do you suggest to emphasize the text on this step to make it clearer?

Hi Team,

I have created the PR #46292 by adding note to clarify the service's expected results, addressing potential confusion among users till cache gets cleared.

Feel free to review and merge the PR

Thanks :)

@vishalbidwe : Thank you for your contribution. I would recommend that you go through our contribution guide before submitting any PR, because there are certain recommendations that we expect our contributors to know about. In this specific case, the PR was supposed to be submitted only if the issue had the triage/accepted label. This is because we do not have sufficient information at hand as to why the requester has submitted this despite having a line that explicitly states to confirm that the service is gone in the docs.

I'll be putting your PR on hold till we receive further response from the requester

@rahul38888 : Please could you advise why this extra line is needed?

Sorry for the late reply.

@adityasamant25 Making sure service in not listed by kubectl get services is not enough. I have seen URL still working even after that. So there should be a note like the one #46292 by @vishalbidwe

@divya-mohan0209 , I think it make sense to have this note as it will provide a complete picture to readers.

@rahul38888 I have personally not experienced this behaviour. However, if you have experienced it and others can verify, then I do not see a harm in emphasizing about waiting for few seconds before the changes take effect.