Change:
The example Deployment resource is duplicated in (code import shortcode and in-line code)
/language en
/kind bug We should keep the shortcode and drop the inline manifest.
/triage accepted /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
we should contain the Service resource following to the Deployment in the as well, right? (or should we create a new file for Service?)
Hey I would like to work on this issue. Do assign me this issue so I can start working on this.
/assign
BTW our convention in SIG Docs is very much that anyone is welcome to start work on an issue, and the best way to indicate that you're starting work is to open a PR (either a draft or the final thing). If anyone else wanted to work on this, please do try to liaise with first.
Thanks for your piece of advice, I will definitely keep this in mind for the next time.
The page to fix is Ah yes. The Service: should go in a new example manifest file and we'll need a second shortcode to cover that. Ideally we also explain how to use to deploy those. For example, for the Deployment, it's
Hey I have linked a PR against this issue, please do review it.
PR is submitted by another first time contributor to address the same problem before this issue was created. I will let other members decide on the best remediation of this situation.
ah sorry, that was my bad, I only searched issues before filing this issue... :bow:
I created PR after I searched both issues and PRs and there was nothing at that time... since this could be my first PR to the repo.
To make PR more likely to be my first contribution to the repo, I have in the beginning, and in addition, a missing step in the middle to get the info of the pods. To promote a bit: PR was created before this issue was created. is and uses the common YAML reference to A single YAML is used so that it can be deleted with a single . A missing step to get the info of the pods is .
Hey i have recently started my journey in open source and want to learn more looking for correct mentorship and guidance. If this issue is not resolved completely in that case can i also work on this??
Hi this issue is already resolved, I've also linked a PR to this issue. You can look for another good-first-issue to get started with.
Hey, anyone working on this, can you assign it to me. /assign
this issue is already resolved. As you can see I've also linked a PR to this issue. You can search for another good-first-issue to get started with.
This issue isn't yet resolved, but at least one reviewable PR is already open with a potential fix.
/assign
/assign
is issuse still open if yes then please assign me with issuse???

Discussion:
{{< codenew file="service/pod-with-graceful-termination.yaml" >}} <del> ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 120 # extra long grace period containers: - name: nginx image: nginx:latest ports: - containerPort: 80 lifecycle: preStop: exec: # Real life termination may take any time up to terminationGracePeriodSeconds. # In this example - just hang around for at least the duration of terminationGracePeriodSeconds, # at 120 seconds container will be forcibly terminated. # Note, all this time nginx will keep processing requests. command: [ "/bin/sh", "-c", "sleep 180" ] </del> <ins> {{< codenew file="service/explore-graceful-termination-nginx.yaml" >}} </ins> <del> --- </del> <ins> Now create the Deployment Pod and Service using the above files: </ins> <del> apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 </del> <ins> ```shell kubectl apply -f pod-with-graceful-termination.yaml kubectl apply -f explore-graceful-termination-nginx.yaml </ins> ``` Once the Pod and Service are running, you can get the name of any associated EndpointSlices:

<ins> apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 </ins>  No newline at end of file