jiebi/CodeConvo huggingface dataset:
Change:
Image: framework.GetPauseImageName(f.Client), }, }, <ins> NodeSelector: map[string]string{k: v}, // only launch on our two nodes, contradicting the podAntiAffinity </ins> }, }) framework.ExpectNoError(err)

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Looking into this...
trying to track this flake down. It looks like the pod is launched despite AntiAffinity in . In my local setup I saw the same, but noticed that the new admission controller was not activate.

I have activate it and now get this:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Should be fixed by
Change:
} var map_ResourcePolicyRule = map[string]string{ <del> "":             "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.", </del> <ins> "":             "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) either (d1) the request does not specify a namespace (i.e., `Namespace==""`) and clusterScope is true or (d2) the request specifies a namespace and least one member of namespaces matches the request's namespace.", </ins> "verbs":        "`verbs` is a list of matching verbs and may not be empty. "*" matches all verbs and, if present, must be the only entry. Required.", "apiGroups":    "`apiGroups` is a list of matching API groups and may not be empty. "*" matches all API groups and, if present, must be the only entry. Required.", "resources":    "`resources` is a list of matching resources (i.e., lowercase and plural) with, if desired, subresource.  For example, [ "services", "nodes/status" ].  This list may not be empty. "*" matches all resources and, if present, must be the only entry. Required.",

Discussion:
<!-- 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 --I looked at the comment on ResourcePolicyRule to understand exactly what its ClusterScope field means, and was dismayed to find an outdated precise description that does not mention that field. I expected that comment to be up to date. Kubernetes version (use ): current 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:
/cc /cc /cc /cc
/triage accepted
Change:
} // invariant: the controller must react to the new pod becoming ready within a reasonable timeframe (2x grace period) <del> for uid, firstSeen := range ageOfOldPod { if now.Sub(firstSeen) > maxSurgeOverlap { errs = append(errs, fmt.Sprintf("An old pod with UID %s has been running alongside a newer version for longer than %s", uid, maxSurgeOverlap)) </del> <ins> for node, uidToTime := range nodeToAgeOfOldPod { for uid, firstSeenSinceNewVersionPod := range uidToTime { if now.Sub(firstSeenSinceNewVersionPod) > maxSurgeOverlap { errs = append(errs, fmt.Sprintf("An old pod with UID %s on a node %s has been running alongside a newer version for longer than %s", uid, node, maxSurgeOverlap)) } </ins> } }

Discussion:
/kind flake /sig apps This is an old flaking since , but the flaky rate is not that high. The rate in recent runs in is about 3/23 ~ 13%.
/priority backlog as the failure rate now is not high /cc old threads in and
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority backlog as the failure rate now is not high /cc old threads in and 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
/priority backlog
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten still flaking
/triage accepted /assign
Change:
} func (rc *resourceMetricsCollector) collectPodMemoryMetrics(ch chan<- metrics.Metric, pod summary.PodStats) { <del> if pod.Memory == nil { </del> <ins> if pod.Memory == nil || pod.Memory.WorkingSetBytes == nil { </ins> return }

Discussion:
kubelet panic when accessing metrics/resource endpoint kubelet log kubelet works fine access metrics/resource endpoint of kubelet No response <details</details<details</details<details</details<details</details<detailsINFO[2022-07-14 05:36:21.474173892Z] Starting CRI-O, version: 1.23.0, git: (dirty) Version: 1.23.0 GitCommit: GitTreeState: dirty BuildDate: 1980-01-01T00:00:00Z GoVersion: go1.17.4 Compiler: gc Platform: linux/amd64 Linkmode: static BuildTags: apparmor, excludegraphdriverdevicemapper, seccomp, selinux SeccompEnabled: true AppArmorEnabled: true </details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/assign
/sig node
Change:
// GetMountRefs : empty implementation here since there is no place to query all mount points on Windows func (mounter *Mounter) GetMountRefs(pathname string) ([]string, error) { <del> pathExists, pathErr := PathExists(normalizeWindowsPath(pathname)) // TODO(#75012): Need a Windows specific IsCorruptedMnt function that checks against whatever errno's // Windows emits when we try to Stat a corrupted mount // https://golang.org/pkg/syscall/?GOOS=windows&GOARCH=amd64#Errno </del> <ins> windowsPath := normalizeWindowsPath(pathname) pathExists, pathErr := PathExists(windowsPath) </ins> if !pathExists { return []string{}, nil <ins> } else if IsCorruptedMnt(pathErr) { klog.Warningf("GetMountRefs found corrupted mount at %s, treating as unmounted path", windowsPath) return []string{}, nil </ins> } else if pathErr != nil { <del> return nil, fmt.Errorf("error checking path %s: %v", normalizeWindowsPath(pathname), pathErr) </del> <ins> return nil, fmt.Errorf("error checking path %s: %v", windowsPath, pathErr) </ins> } return []string{pathname}, nil }

Discussion:
<!-- 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: pod with smb(cifs) mount could not be terminated on Windows when that smb account is invalid, the pod will be stuck forever What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with azure file mount on Windows the storage account of azure file invalid the pod with azure file mount could not be terminated forever Anything else we need to know?: similar to case: Environment: Kubernetes version (use ): v1.12.6 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /assign /sig windows
Change:
# gcutil will print the "external-ip" column header even if no instances are found local minion_ip=$(gcutil listinstances --format=csv --sort=external-ip  --columns=external-ip --zone ${ZONE} --filter="name eq ${MINION_NAMES[$i]}"  <del> | tail --lines=+2 | tail -n 1) </del> <ins> | tail -n '+2' | tail -n 1) </ins> if [ -z "$minion_ip" ] ; then echo "Did not find ${MINION_NAMES[$i]}" 1>&2 else

Discussion:
It fails with The change seems to have been introduced in - Redirects error messages to stderr so users can see them. /cc
Sorry about that. Fix sent.
Change:
return fmt.Errorf("error querying security groups: %v", err) } <ins> taggedSecurityGroups, err := s.getTaggedSecurityGroups() if err != nil { return fmt.Errorf("error querying for tagged security groups: %v", err) } </ins> // Open the firewall from the load balancer to the instance // We don't actually have a trivial way to know in advance which security group the instance is in // (it is probably the minion security group, but we don't easily have that).

Discussion:
If there are two security groups on an instance, we currently make an arbitrary choice. We should choose based on tags, as we normally do. For back-compat, we need to cope if there is one security group and it is not tagged. We should make sure kube-up tags our security groups, though it isn't really required for kube-up, but it is just good behaviour. cf
Change:
} procFs := procfs.NewProcFS() <del> imageBackOff := util.NewBackOff(resyncInterval, MaxContainerBackOff) </del> <ins> imageBackOff := util.NewBackOff(backOffPeriod, MaxContainerBackOff) </ins> klet.livenessManager = proberesults.NewManager()

Discussion:
I'm not sure if this e2e test is really owned by you-- feel free to find a better owner if you think it's appropriate.
Reassigning to the author of this test.
I'm assigning this off to for triage by the kubelet team. The root cause is that a DNS query on image pull failed, and then we backed off the image pull...
Is it possible caused by your recent change of syncLoop's interval?
fwiw, this looks like a flake in the VM networking, but we should probably retry more aggressively.
No. In the case of sync error, we'll sync again in 10s (which is the same as the old sync interval). As suggests, this is caused by image pulling backoff.
I suspect the backoff algorithm is using the newly introduced sync interval you here.
is right about image backoff reusing the sync period. Uploaded a PR to fix this.
The test failed again
I think you re-open this by mistake. From above jenkins link, the failing test is "07:31:59 [BFA] Found failed test case: Kubectl client Simple pod should support exec through an HTTP proxy", not the one reported here. I am filing a separate issue for a better tracking.
Filed . Thanks!
Apologies for the confusion. Thanks a lot
I encountered this here: https://00e9e64bacc10db5eb724c1d4d4d23cf4fe70262b526a039cf-
Updated link to Derek's log: It turns out that doesn't check the return value from the function call, so it allows the test to proceed when it should instead fail. I can try to do a PR for that tomorrow if nobody gets to it first.
So the PR seemed easy enough...
I looked at the logs from in more detail. Here is the sequence of events: 21:41:15. - pod received by kubelet 21:46:16. - pod killed (5 minute timeout from the e2e test) 21:47:01. - server recorded the image pull finished (event rejected because the namespace had already been deleted) I realize this is from May 3rd, and we've been tweaking the Docker operation and/or image pulling timeouts since then, but I at least wanted to capture what had happened.
Let's dup this to the slow image-pulling bug:
Change:
func TestNewCmdVersionWithoutConfigFile(t *testing.T) { tf := cmdutil.NewFactory(&genericclioptions.ConfigFlags{}) streams, _, buf, _ := genericclioptions.NewTestIOStreams() <del> cmd := NewCmdVersion(tf, streams) cmd.SetOutput(buf) if err := cmd.Execute(); err != nil { </del> <ins> o := NewOptions(streams) if err := o.Complete(tf, &cobra.Command{}); err != nil { t.Errorf("Unexpected error: %v", err) } if err := o.Validate(); err != nil { t.Errorf("Unexpected error: %v", err) } // FIXME soltysh: // since we have defaulting to localhost:8080 in staging/src/k8s.io/client-go/tools/clientcmd/client_config.go#getDefaultServer // we need to ignore the localhost:8080 server, when above gets removed this should be dropped too if err := o.Run(); err != nil && !strings.Contains(err.Error(), "localhost:8080") { </ins> t.Errorf("Cannot execute version command: %v", err) } if !strings.Contains(buf.String(), "Client Version") {

Discussion:
What happened: I am using a command like below in GitHub actions: I get the following error: What you expected to happen: Since I am using flag, it should work without requiring a valid kubeconfig file. How to reproduce it (as minimally and precisely as possible): Just delete your local kubeconfig file and try the above command. Anything else we need to know?: Environment: Kubernetes version (use ): 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 cli
/assign /kind regression
This likely breaks some scripted usage of kubectl
This is related to /assign
Or
Yes, sorry I mentioned you in this issue. Because my first thought is this brings and which will check the config file existence but in fact that's not the root cause. Actually the root cause This checks config has the server or not. And with this , this function will return error when there's no local config file. I think there might be two solutions? the similar logic like to every , , ..... when or is set. Seems not a good idea. reverse this to have the default server which is better than ? By the way, is equals ? Since This works only for .
The plan I agreed on with Jordan is that I will revert since that seems to be the main culprit behind all these problems. I'll add a test ensuring this works as required. This will allow us to backport the fix to 1.18. For 1.19 I'll put together a proper fix supporting and flags.
Change:
// If the resource referred to by volumeAttributesClass does not exist, this PersistentVolumeClaim will be // set to a Pending state, as reflected by the modifyVolumeStatus field, until such as a resource // exists. <del> // More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#volumeattributesclass </del> <ins> // More info: https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/ </ins> // (Alpha) Using this field requires the VolumeAttributesClass feature gate to be enabled. // +featureGate=VolumeAttributesClass // +optional

Discussion:
in link is out of date. the new one is fix link none No response <details</details<detailsnone </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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 storage /kind documentation /remove-kind bug
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "$KUBE_ROOT/build/common.sh" <ins> if ${KUBE_ROOT}/cluster/kubectl.sh version | grep Client | grep dirty; then echo "!!! Tag at invalid point, or something else is bad. Build is dirty. Don't push this build." >&2 exit 1 fi </ins> kube::release::gcs::release kube::release::gcs::publish_latest_official

Discussion:
Since I've been having troubles with installation, I've digged a bit and found out that the permissions inside Kubernetes tarballs changed between 0.16.0 and 0.17.0. I've downloaded both tarballs, extracted them into separate directories and then extracted the Kubernetes server tarballs. This is what I get: I suppose, there has been a concious decision to restrict the world's access to those binaries. However, this breaks the installation routine mentioned above and probably makes life a bit more difficult in several other places. I'd be thankful for a correction if this wasn't intended or a pointer to the appropriate commit it this is legit -- I'd correct the installation.
assigning this to you to decide who the eventual assignee should be :)
Any news on this front? 0.20.1 is still restricted.
Apologies for the issue. It wasn't intentional -- likely an artifact of build scripts being run by different people? I'll check out 0.20.2 as I build it to make sure it has the right perms.
Apologies, but 0.20.2 didn't include fixed permissions. I now understand the issue, : "make release" builds a tarball using the permissions on files in your local git tree. I had "umask 027" set when I cloned, so those in-the-repo files had no world-readable perms. Setting "umask 022" before running "make release" is not enough -- it has to be part of creating the local tree when cloning. I'll update instructions and the next release (20.3 or 21.0) should fix this issue. And longer term, we need to put a bit more effort into releasing from a known-good environment and not rely on a developer's workstation's idiosyncrasies -- sorry this bit you.
I can't repro Trying again a different way, but I don't think the umask before clone should do anything (in particular, umasks aren't "sticky" on files, they're sticky to processes.)
And let's pretend on my personal fork isn't woefully out of date (who uses master on their personal fork? I should really just delete that that thing.) Comment updated.
Ah, I see the problem now.

works fine for the server tar, but the full tar also packages examples, etc., and for that, tar tends to just pick up the permissions of the git tree. Got it.
I'll take this. I'm going to write a script to build official bits, and this is easy enough to fix along the way.
Seems not fixed as of Kubernetes 1.0.7
sorry about that. is doing the 1.1.1 release and has been improving release scripts -- is 1.1.1 good re: permissions?
was not built by .
Reassigning to as release-oncall. Quinton, I can mentor or advise as necessary.
And yeah, is fine: There's no real bug here. There was a process issue that occurred with 1.0.7. We can rebuild the binaries if we need to.
FYI, leaving this issue closed, as per 's comment above. If anyone disagrees, please re-open this issue.
Change:
# limitations under the License. # This script will set up the salt directory on the target server.  It takes one <del> # argument that is a tarball with the pre-compiled kuberntes server binaries. </del> <ins> # argument that is a tarball with the pre-compiled kubernetes server binaries. </ins> set -o errexit set -o nounset

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
ssh := history.NewFakeHistory(informerFactory.Apps().V1beta1().ControllerRevisions()) ssc.podListerSynced = alwaysReady ssc.setListerSynced = alwaysReady <del> ssc.control = NewDefaultStatefulSetControl(fpc, ssu, ssh) </del> <ins> recorder := record.NewFakeRecorder(10) ssc.control = NewDefaultStatefulSetControl(fpc, ssu, ssh, recorder) </ins> return ssc, fpc }

Discussion:
An issue to make bot happy for When StatefulSet finds any of its pods in phase Failed it will delete it and create it again. While doing so it will emit delete+create event which is really confusing for the user as he has no idea what's happening. /sig apps
Change:
ginkgo.Describe("NFSv4", func() { ginkgo.It("should be mountable for NFSv4", func() { config, _, serverIP := volume.NewNFSServer(c, namespace.Name, []string{}) <del> defer volume.TestCleanup(f, config) </del> <ins> defer volume.TestServerCleanup(f, config) </ins> tests := []volume.Test{ {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in