jiebi/CodeConvo huggingface dataset:
Code change:
Update , job-tracking-with-finalizers section, as k/k PR is disabling by default due to an unresolved bug.
Specifically the note () says that "it is enabled by default."
this feature is currently enabled by default in v1.23 and will be disabled in v1.24, right?
/sig apps /language en
I also proposed to disable it by default in 1.23 , but the release managers haven't approved it yet.
/triage accepted /sig apps
/assign
Thanks

Related discussion:
text: [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <del> It is enabled by default. </del> When enabled, the control plane tracks new Jobs using the behavior described below. Jobs created before the feature was enabled are unaffected. As a user,
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The link at the top of the homepage () seems to currently redirect to I assume this is the same issue as Proposed Solution: Remove the /dockershim alias from the ZH blog page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Same symptoms, different PR. /triage accepted Thanks. /priority important-soon
/assign

Related discussion:
text: title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> <ins> aliases: [ '/zh/dockershim' ] </ins> --- <!-- layout: blog
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">criSocket</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;/var/run/dockershim.sock&#34;</span><span style="color:#bbb"> </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">taints</span>:<span style="color:#bbb"> </span><span style="color:#bbb">    </span>- <span style="color:#000;font-weight:bold">key</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;kubeadmNode&#34;</span><span style="color:#bbb"> <del> </span><span style="color:#bbb">      </span><span style="color:#000;font-weight:bold">value</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;master&#34;</span><span style="color:#bbb"> </del> <ins> </span><span style="color:#bbb">      </span><span style="color:#000;font-weight:bold">value</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;someValue&#34;</span><span style="color:#bbb"> </ins> </span><span style="color:#bbb">      </span><span style="color:#000;font-weight:bold">effect</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;NoSchedule&#34;</span><span style="color:#bbb"> </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">kubeletExtraArgs</span>:<span style="color:#bbb"> </span><span style="color:#bbb">    </span><span style="color:#000;font-weight:bold">v</span>:<span style="color:#bbb"> </span><span style="color:#099">4</span><span style="color:#bbb">
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: </td> <td> <p><code>tlsBootstrapToken</code> is a token used for TLS bootstrapping. <del> If <code>bootstrapToken</code> is set, this field is defaulted to <code>.bootstrapToken.token</code>, but can be overridden. If <code>file</code> is set, this field <strong>must be set</strong> in case the KubeConfigFile does not </del> <ins> If <code>bootstrapToken</code> is set, this field is defaulted to <code>.bootstrapToken.token</code>, but can be overridden. If <code>file</code> is set, this field <strong>must be set</strong> in case the KubeConfigFile does not </ins> contain any other authentication information.</p> </td> </tr>
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: <code>string</code> </td> <td> <del> <p><code>criSocket<code> is used to retrieve container runtime information. This information will </del> <ins> <p><code>criSocket</code> is used to retrieve container runtime information. This information will </ins> be annotated to the Node API object, for later re-use.</p> </td> </tr>
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: </td> <td> <p><code>taints</code> specifies the taints the Node API object should be registered with. <del> If this field is unset, i.e. nil, in the <code>kubeadm init</code> process it will be defaulted to <code>'node-role.kubernetes.io/master=&quot;&quot;'</code>. If you don't want to taint your control-plane node, set this field to an empty list, i.e. <code>taints: []</code> in the YAML file. This field is </del> <ins> If this field is unset, i.e. nil, in the <code>kubeadm init</code> process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list, i.e. <code>taints: []</code>, in the YAML file. This field is </ins> solely used for Node registration.</p> </td> </tr>
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">criSocket</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;/var/run/dockershim.sock&#34;</span><span style="color:#bbb"> </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">taints</span>:<span style="color:#bbb"> </span><span style="color:#bbb">  </span>- <span style="color:#000;font-weight:bold">key</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;kubeadmNode&#34;</span><span style="color:#bbb"> <del> </span><span style="color:#bbb">    </span><span style="color:#000;font-weight:bold">value</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;master&#34;</span><span style="color:#bbb"> </del> <ins> </span><span style="color:#bbb">    </span><span style="color:#000;font-weight:bold">value</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;someValue&#34;</span><span style="color:#bbb"> </ins> </span><span style="color:#bbb">    </span><span style="color:#000;font-weight:bold">effect</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;NoSchedule&#34;</span><span style="color:#bbb"> </span><span style="color:#bbb">  </span><span style="color:#000;font-weight:bold">kubeletExtraArgs</span>:<span style="color:#bbb"> </span><span style="color:#bbb">    </span><span style="color:#000;font-weight:bold">v</span>:<span style="color:#bbb"> </span><span style="color:#099">4</span><span style="color:#bbb">
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

Related discussion:
text: </td> <td> <p><code>tains</code> specifies the taints the Node API object should be registered with. <del> If this field is unset, i.e. nil, in the <code>kubeadm init</code> process it will be defaulted to <code>taints: [&quot;node-role.kubernetes.io/master:&quot;&quot;]</code>. If you don't want to taint your control-plane node, set this field to an empty slice, </del> <ins> If this field is unset, i.e. nil, in the <code>kubeadm init</code> process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list, </ins> i.e. <code>taints: []</code> in the YAML file. This field is solely used for Node registration.</p> </td> </tr>
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign

Related discussion:
text: To apply Pod Security Standards to specific namespaces, refer to [Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss). <ins> If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, check the documentation for that version. </ins> ## {{% heading "prerequisites" %}} Install the following on your workstation:
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign

Related discussion:
text: 1. Create a cluster with no Pod Security Standards applied: ```shell <del> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 </del> <ins> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0 </ins> ``` The output is similar to this: ``` Creating cluster "psa-wo-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️
Code change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign

Related discussion:
text: these Pod Security Standards: ```shell <del> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml </del> <ins> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml </ins> ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️
Code change:
Simple documentation issue: Section for "CertificateSubjectRestriction" admission controller is "CertificateSubjectRestrictions". The appended 's' is not valid and will prevent apiserver startup if used in --disable-admission-plugins. Note: plugin is listed correctly in the 'defaults' list.
Fixed by /close
Closing this issue. <detailsIn response to : Fixed by /close 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
/triage accepted /language en

Related discussion:
text: See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more information on the permissions required to perform different actions on CertificateSigningRequest resources. <del> ### CertificateSubjectRestrictions {#certificatesubjectrestrictions} </del> <ins> ### CertificateSubjectRestriction {#certificatesubjectrestriction} </ins> This admission controller observes creation of CertificateSigningRequest resources that have a `spec.signerName` of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute')
Code change:
Just above this anchor #node-affinity-per-scheduling-profile, the note block is referring to the Pod spec pod-with-node- 2 above, but it's placement appears to refer to the one immediately above. It takes a little bouncing around the page to sort it out :)
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 label. The label can be by org members by writing in a comment. <detailsInstructions 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

Related discussion:
text: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: