jiebi/CodeConvo huggingface dataset:
Code change:
/* Release : v1.23 Testname: Pod Lifecycle, poststart https hook <del> Description: When a post-start handler is specified in the container lifecycle using a 'HttpGet' action, then the handler MUST be invoked before the container is terminated. A server pod is created that will serve https requests, create a second pod with a container lifecycle specifying a post-start that invokes the server pod to validate that the post-start is executed. </del> <ins> Description: When a post-start handler is specified in the container lifecycle using a 'HttpGet' action, then the handler MUST be invoked before the container is terminated. A server pod is created that will serve https requests, create a second pod on the same node with a container lifecycle specifying a post-start that invokes the server pod to validate that the post-start is executed. </ins> */ ginkgo.It("should execute poststart https hook properly [MinimumKubeletVersion:1.23] [NodeConformance]", func() { lifecycle := &v1.Lifecycle{

Related discussion:
text: I've submitted the fix via PR
This issue is also affecting 1.25 tests: If possible, we should cherry-pick to the release-1.25 branch once it's merged on master.
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-controller repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the kube-aggregator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the code-generator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area code-generation /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the client-go repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area apiserver /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apimachinery repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

Related discussion:
text: The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiextensions-apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
Code change:
func (detacher *vsphereVMDKDetacher) Detach(volumeName string, nodeName types.NodeName) error { volPath := getVolPathfromVolumeName(volumeName) <del> attached, err := detacher.vsphereVolumes.DiskIsAttached(volPath, nodeName) </del> <ins> attached, newVolumePath, err := detacher.vsphereVolumes.DiskIsAttached(volPath, nodeName) </ins> if err != nil { // Log error and continue with detach klog.Errorf(

Related discussion:
text: When user creates a static PV using folder name in path: on vSAN backed datastore then detach disk does not work because check fails - The code expects folder name to be UUID but it does not and hence it determines disk is not attached to the node and hence no detach is ever performed. /sig storage cc
Code change:
prepare-e2e while true; do <del> ${KUBECTL} --watch-only get events </del> <ins> ${KUBECTL} get events --watch-only </ins> done

Related discussion:
text: This is the script that runs to capture event output during e2e runs: It's failing after the recent pflag merge:
cc
Or something. I might be completely off. But something broke it recently enough, and I know like his event log.
That command is actually invalid. is a flag on the command, not the root. Fix in
Code change:
], "volumes": [{ "name":"kubectl", <del> "hostPath":{"path": "/usr/bin/kubectl"} </del> <ins> "hostPath":{"path": "$KUBECTL_PATH"} </ins> }] } }

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes
Code change:
], "volumes": [{ "name":"kubectl", <del> "hostPath":{"path": "/usr/bin/kubectl"} </del> <ins> "hostPath":{"path": "$KUBECTL_PATH"} </ins> }] } }

Related discussion:
text: e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Are you the correct assignee for this? If so, can you please give an update. If not, can you please reassign it to the correct person. CC
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Yes, I guess so. I'm looking into it.
Code change:
], "volumes": [{ "name":"kubectl", <del> "hostPath":{"path": "/usr/bin/kubectl"} </del> <ins> "hostPath":{"path": "$KUBECTL_PATH"} </ins> }] } }

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
We need to get this fixed soon and picked up in release-1.5 since it is consistently red in
ack i have a PR currently running
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
If you found the root cause, we will close my pending PR that printing out some debug info. What is the PR # of the commit you mentioned above?
Code change:
], "volumes": [{ "name":"kubectl", <del> "hostPath":{"path": "/usr/bin/kubectl"} </del> <ins> "hostPath":{"path": "$KUBECTL_PATH"} </ins> }] } }

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
: here it is
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
We timeout waiting for pod sometimes. Is it reasonable to use a longer timeout? Use for in that test.
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
: sure thing, do you want to do that in a fresh PR?
I updated my pending PR .
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Code change:
readCloser, err := client.RESTClient.Get(). Prefix("proxy"). <del> Resource("minions"). </del> <ins> Resource("nodes"). </ins> Name(pod.Spec.Host). Suffix("containerLogs", namespace, podID, container). Param("follow", strconv.FormatBool(follow)).

Related discussion:
text: kubectl log stops working for me all the sudden: A little bit digging into the issue, I found the problem is only limited to /v1beta3: Query /v1beta1 Query through v1beta3
cc/
Does replacing "minions" by "nodes" work?
Cool, looks like it should be a simple kubectl fix, I will do it shortly.
Code change:
}, "fieldRef": { "$ref": "#/definitions/io.k8s.api.core.v1.ObjectFieldSelector", <del> "description": "Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs." </del> <ins> "description": "Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['<KEY>']`, `metadata.annotations['<KEY>']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs." </ins> }, "resourceFieldRef": { "$ref": "#/definitions/io.k8s.api.core.v1.ResourceFieldSelector",

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When I tried to create a pod with env variables referencing to annotations: What you expected to happen: Should Proceed. As in It stated is a valid option How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig docs
The API docs need to be updated to indicate the correct supported values. See for correct values
You are a lifesaver. Thank you!
/assign I can try to update the api documentation
Code change:
return false, nil } <ins> func (f *FakeMounter) EvalHostSymlinks(pathname string) (string, error) { return pathname, nil } </ins> func (f *FakeMounter) PrepareSafeSubpath(subPath Subpath) (newHostPath string, cleanupAction func(), err error) { return subPath.Path, nil, nil }

Related discussion:
text: /kind bug Using , if a block device is symlinked to the discovery directory e.g. , then MapVolume will fail with since the containerized kubelet cannot see the path on host. is mounted by containerized kubelet, so if before we try to map the device we set devicePath to the evaluation of symlink and end up with a devicePath of , containerized kubelet will see the device and successfully map the device. Are there any issues with this solution? This is on Kubernetes 1.10
/sig storage
ah yes containerized kubelet has many issues when dealing with symlinks. Check out Mounter.GetMode(), it calls a nsenter EvalSymlinks which should be able to do what you need. But actually, one thing to consider, is do you need to do the losetup on the host, or does inside the container work?
Yes it appears to work from inside the container, on the host I run which disappears after I delete the pod using the device. My understanding of running losetup in MapVolume is not that great but I suppose that as long as that /dev/loop0 is created we are fine. Thanks for the quick response, I'll create a PR using that function and tag you
Does it create it on the host or in the containerized kubelet? What happens when containerized kubelet is restarted? The purpose of losetup is to do "refcounting" on the block device to prevent possible naming collisions when devices are attached/detached under unhealthy conditions. Ie, if a device showed up as /dev/sdb and you gave that to a pod, and then for some reason it become unhealthy and disappeared (while the pod is still running), another device (maybe even another volume type) could get attached to the node and reuse /dev/sdb. Now the pod has access to a device it's not supposed to. With filesystem volumes, the refcounting is done with mount points, but for block device, loopback is the equivalent.
It is created on the host (and also visible in the container), and stays around through restart. I understand now, thank you.
Actually after I restart it becomes /vdb instead of /dev/vdb in the losetup output, idk what that is about.