jiebi/CodeConvo huggingface dataset:
Change:
} return false } <ins> func isStreamReset(err error) bool { if err == nil { return false } if urlErr, ok := err.(*url.Error); ok { // Sadly, the client does not receive a more specific indication // of stream reset. return strings.Contains(urlErr.Err.Error(), "INTERNAL_ERROR") } return false } </ins>

Discussion:
pull-kubernetes-unit TestPriorityAndFairnessWithPanicRecoveryAndTimeoutFilter 7/14 No response /sig api-machinery
/priority important-soon
/cc /triage accepted
and can this be related to ?
I see no direct relationship, but hey, anything's possible. We learned that with the misery in integration test failures when we merged not-really-guilty other stuff.
The expanded logging turned up some new evidence. See , where the complaint is now
The problem here is not APF, it is something in the timeout filter or the test server.
is something in APF triggering a timeout?
The flake definitely came in with on the prior commit on master: on the merge commit of
/assign
Note that the flaking test is deliberately suffering server-side timeouts. The symptom in flakes is that the test is checking that the client gets kube's designed response to a timeout while handling, a particular form HTTP response message, but sometimes the client gets something else (an http2 internal error?). is a change in metrics, and should have nothing to do with how timeouts while handling and detected or handled. I will see what I can see...
, regarding your comment above (): note that the output shown (the panic "as designed") is normal; if there are failures involved, the failing part was elided.
Also, the failures seem to be coming from one particular subtest () and that one does not involve designed panics.
On closer examination of the timeout filter, it appears that this "INTERNAL ERROR" is something that can happen normally in the course of handling a timeout. So I will adjust the test to accept this.
I have updated to include the fix for this flake.
Change:
"time" batch "k8s.io/api/batch/v1" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels"

Discussion:
If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.
Change:
}), ) for arch in archs] for os, archs in SERVER_PLATFORMS.items()] <del> # The mondo test tarball is deprecated. pkg_tar( name = "_test-mondo-bin", srcs = ["//build:test-targets"], mode = "0755", package_dir = select(for_platforms( for_test = "platforms/{OS}/{ARCH}", )), tags = [ "manual", "no-cache", ], visibility = ["//visibility:private"], ) genrule( name = "kubernetes-test-mondo-deprecation", outs = ["DEPRECATION_NOTICE"], cmd = """cat <<EOF >$@ The mondo test tarball containing binaries for all platforms is DEPRECATED as of Kubernetes 1.14. Users of this tarball should migrate to using the platform-specific tarballs in combination with the "portable" tarball which contains scripts, test images, and other manifests. For more details, please see KEP sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball. EOF """, visibility = ["//visibility:private"], ) # The mondo test tarball is deprecated. # This one was never really correct, anyway, since we can't include # binaries from multiple platforms in a single tarball. pkg_tar( name = "kubernetes-test", srcs = [ ":kubernetes-test-mondo-deprecation", "//build:test-portable-targets", ], extension = "tar.gz", package_dir = "kubernetes", remap_paths = { "build/release-tars/DEPRECATION_NOTICE": "DEPRECATION_NOTICE", }, strip_prefix = "//", tags = [ "manual", "no-cache", ], deps = select(for_platforms( for_test = [":_test-mondo-bin"], )), ) </del> pkg_tar( name = "kubernetes-test-portable", srcs = ["//build:test-portable-targets"],

Discussion:
What happened: On 2019-02-22 was merged with an indication that the mondo test tarball noted as deprecated as per But it did not include a timeline for eventual removal. What you expected to happen: It's been 7 months now. We should formalize a plan for removal. /sig testing /sig release /kind cleanup /priority important-soon
Enhancement tracking issue ref:
removes the deprecated mondo test tarball.
Change:
} } if len(nper.To) == 0 { <del> w.Write(LEVEL_0, "%s%sn", initialIndent, "To: <any> (traffic not restricted by source)") </del> <ins> w.Write(LEVEL_0, "%s%sn", initialIndent, "To: <any> (traffic not restricted by destination)") </ins> } else { for _, to := range nper.To { w.Write(LEVEL_0, "%s%sn", initialIndent, "To:")

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: A NetworkPolicy to allow egress to all Pods should use the term "destination" instead of "source" while example: What you expected to happen: should instead be kubectl describe networkpolicy net-document Name: net-document Namespace: default Created on: 2020-07-15 18:16:46 -0700 PDT Labels: <noneAnnotations: {"apiVersion":"","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"net-document","namespace":"default"},"spe... Spec: PodSelector: app=test-document Allowing ingress traffic: To Port: <any(traffic allowed to all ports) From: <any(traffic not restricted by source) Allowing egress traffic: To Port: 80/TCP To: <any(traffic not restricted by destination) Policy Types: Egress, Ingress `` How to reproduce it (as minimally and precisely as possible): Create a allow-all egress NetworkPolicy and do
/sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-network 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
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/sig cli As this is something specific from kubectl :)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cli 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
/assign
/remove-triage unresolved
Change:
<ins> load("@io_bazel_rules_go//go:def.bzl", "go_library", "go_test") go_library( name = "go_default_library", srcs = ["logs.go"], importpath = "k8s.io/kubernetes/pkg/kubelet/kuberuntime/logs", visibility = ["//visibility:public"], deps = [ "//pkg/kubelet/apis/cri:go_default_library", "//pkg/kubelet/apis/cri/v1alpha1/runtime:go_default_library", "//pkg/util/tail:go_default_library", "//vendor/github.com/docker/docker/pkg/jsonlog:go_default_library", "//vendor/github.com/fsnotify/fsnotify:go_default_library", "//vendor/github.com/golang/glog:go_default_library", "//vendor/k8s.io/api/core/v1:go_default_library", ], ) go_test( name = "go_default_test", srcs = ["logs_test.go"], importpath = "k8s.io/kubernetes/pkg/kubelet/kuberuntime/logs", library = ":go_default_library", deps = [ "//vendor/github.com/stretchr/testify/assert:go_default_library", "//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", ], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], visibility = ["//visibility:public"], ) </ins>

Discussion:
We should make the CRI log parsing code in kubelet to be a library. So that container runtimes and external tools don't need to copy the whole code ( vendor it instead ). Referring
/assign
/sig node
I can help on it.
/assign
GitHub didn't allow me to assign the following users: yanxuean. Note that only can be assigned. <detailsIn response to : /assign 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
Thanks. I have a branch ready for this. Will open a PR later and ping you when it is out.
ok
Change:
return list } <del> // Contains returns a util.StringSet containing all IDs of stored the items. </del> <ins> // ContainedIDs returns a util.StringSet containing all IDs of stored the items. </ins> // This is a snapshot of a moment in time, and one should keep in mind that // other go routines can add or remove items after you call this. <del> func (c *cache) Contains() util.StringSet { </del> <ins> func (c *cache) ContainedIDs() util.StringSet { </ins> c.lock.RLock() defer c.lock.RUnlock() set := util.StringSet{}

Discussion:
The client/cache interface has a method which is supposed to return a of the IDs in a store. This is a bit misleading and should probably be renamed to 'Contents' or 'ContainedIDs'.
Thoughts
I tend to agree. contains to me should always return a bool and take an input key. Sent from my iPhone
Yeah, I agree, both of the suggested names would be an improvement.
Change:
name: new-kms-provider-for-configmaps cachesize: 1000 endpoint: unix:///@new-kms-provider.sock <del> - resources: - '*.*' providers: - kms: name: kms-provider-to-encrypt-all cachesize: 1000 endpoint: unix:///@new-encrypt-all-kms-provider.sock - identity: {} </del> ` <del> // start new KMS Plugin _ = mock.NewBase64Plugin(t, "@new-encrypt-all-kms-provider.sock") </del> // update encryption config and wait for hot reload <del> if err := os.WriteFile(filepath.Join(test.configDir, encryptionConfigFileName), []byte(encryptionConfigWithoutOldProvider), 0644); err != nil { t.Fatalf("failed to update encryption config, err: %v", err) } wantPrefixForEncryptAll := "k8s:enc:kms:v1:kms-provider-to-encrypt-all:" </del> <ins> updateFile(t, test.configDir, encryptionConfigFileName, []byte(encryptionConfigWithoutOldProvider)) </ins> // wait for config to be observed <del> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, wantPrefixForEncryptAll, test) </del> <ins> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, test) </ins> // confirm that reading secrets still works _, err = test.restClient.CoreV1().Secrets(testNamespace).Get(

Discussion:
transformation expandless | 14m1s Failed; === RUN TestEncryptionConfigHotReload TestEncryptionConfigHotReload When I see this flake, 10-09 is the first one.(But the job history in the testgrid only started from 10-03) some PR that may be related: /sig auth /cc
/cc
/triage accepted
/cc failed two times in recent 3 runs:
/reopen as of this is still .
Reopened this issue. <detailsIn response to : /reopen 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
Change:
} } <del> // Mount : mounts source to target as NTFS with given options. </del> <ins> // Mount : mounts source to target with given options. // currently only supports cifs(smb), bind mount(for disk) </ins> func (mounter *Mounter) Mount(source string, target string, fstype string, options []string) error { target = normalizeWindowsPath(target) if source == "tmpfs" { <del> klog.V(3).Infof("azureMount: mounting source (%q), target (%q), with options (%q)", source, target, options) </del> <ins> klog.V(3).Infof("mounting source (%q), target (%q), with options (%q)", source, target, options) </ins> return os.MkdirAll(target, 0755) }

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!--What happened: azure file remount on Windows in same node would fail What you expected to happen: If user delete a pod with azure file mount in deployment and it would probably schedule a pod on same node, azure file mount will fail since command would fail if file share is already mounted on the node: It's related to bug: Error logs would be like following: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9-v1.12, master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign
/sig windows
/sig azure
/milestone v1.14 cc This may be good to backport to 1.12 or 1.13 too if customers are using those versions.
Change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/util/net" </ins> clientsetfake "k8s.io/client-go/kubernetes/fake" clienttesting "k8s.io/client-go/testing" extenderv1 "k8s.io/kube-scheduler/extender/v1"

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <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 scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
// RecordNodeEvent records a event related to a node. func RecordNodeEvent(recorder record.EventRecorder, nodeName, nodeUID, eventtype, reason, event string) { ref := &v1.ObjectReference{ <del> Kind:      "Node", Name:      nodeName, UID:       types.UID(nodeUID), Namespace: "", </del> <ins> APIVersion: "v1", Kind:       "Node", Name:       nodeName, UID:        types.UID(nodeUID), Namespace:  "", </ins> } klog.V(2).Infof("Recording %s event message for node %s", event, nodeName) recorder.Eventf(ref, eventtype, reason, "Node %s event: %s", nodeName, event)

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: I'm attempting to use an watcher to better re-act to cluster modifications. I've received the below event: What you expected to happen: I would expect the to include attribute. Not sure if it's all node events or just this particular one. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: bare metal, rancher's rke OS (e.g: ): centos host nodes Kernel (e.g. ): 3.18, 4.4 Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
Just got another from kubelet..
/remove-sig api-machinery /sig node
recording code is here:
Change:
/* Testname: Service, update NodePort, same port different protocol <del> Description: Create a service of type ClusterIP to accept TCP requests. Service creation MUST be successful by assigning ClusterIP to the service. When service type is updated to NodePort to support two protocols i.e. TCP and UDP for same assigned service port 80, service update MUST be successful by allocating two NodePorts to the service. TODO: Test Service reachability, good to include this check in Conformance perspective. </del> <ins> Description: Create a service to accept TCP requests. By default, created service MUST be of type ClusterIP and an ClusterIP MUST be assigned to the service. When service type is updated to NodePort supporting TCP protocol, it MUST be reachable on nodeIP over allocated NodePort to serve TCP requests. When this NodePort service is updated to use two protocols i.e. TCP and UDP for same assigned service port 80, service update MUST be successful by allocating two NodePorts to the service and service MUST be able to serve both TCP and UDP requests over same service port 80. </ins> */ <del> ginkgo.It("should be able to update NodePorts with two same port numbers but different protocols", func() { </del> <ins> ginkgo.It("should be able to update service type to NodePort listening on same port number but different protocols", func() { </ins> serviceName := "nodeport-update-service" ns := f.Namespace.Name jig := e2eservice.NewTestJig(cs, serviceName)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Following are two e2e testing service functioning over same port but different protocol, but do not test service reachability. be able to update NodePorts with two same port numbers but different protocols use same NodePort with same port but different protocols Note: Both the e2e are verifying the same behavior of "service using same port but different protocols" differs in and . Primary goal: Test service reachability for these E2Es. Secondary goal: As both the above e2e are verifying same E2E behavior, it's good to have single e2e in spite of 2 differing in "updating" and "create only" nodePort service. For "create only", suite has another specific e2e . Why is this needed: E2E Improvement and make e2e eligible for Conformance. Service related e2e are getting promoted in /area conformance /sig testing /assign
Change:
} defer a.queue.Done(key) <del> err := a.reconcileKey(key.(string)) if err == nil { // don't "forget" here because we want to only process a given HPA once per resync interval return true </del> <ins> deleted, err := a.reconcileKey(key.(string)) if err != nil { utilruntime.HandleError(err) } // Add request processing HPA after resync interval just in case last resync didn't insert // request into the queue. Request is not inserted into queue by resync if previous one wasn't processed yet. // This happens quite often because requests from previous resync are removed from the queue at the same moment // as next resync inserts new requests. if !deleted { a.queue.AddRateLimited(key) </ins> } <del> a.queue.AddRateLimited(key) utilruntime.HandleError(err) </del> return true }

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!--What happened: Resync period for HorizontalPodAutoscaler controller is set to 15 seconds in order to update HPAs every 15 seconds. Sometimes updates are skipped and period between two updates is 30 seconds. What you expected to happen: HPA should be updated every 15 seconds. How to reproduce it (as minimally and precisely as possible): Add debugs to HPA controller showing how often HPAs are processed. Create HPA. Anything else we need to know?: HPA controller uses rate RateLimitingQueue: New requests are always with 15 seconds delay: If request for the given HPA is in the queue then newly request is skipped. Requests are and removed from the queue at the same moment so there is a race condition. See following scenario: 00:00:00 - Resync adds request to queue to be executed at 00:00:15 00:00:15 - Resync adds next request to queue to be executed at 00:00:30 but it is skipped because previous request is still in the queue 00:00:15 - Request at 00:00:00 is executed 00:00:30 - Resync adds next request to queue to be executed at 00:00:45 00:00:45 - Request at 00:00:30 is executed In above scenario HPA wasn't updated between 00:00:15 and 00:00:45. Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: GKE <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig autoscaling
/assign krzysztof-jastrzebski
Change:
import ( "fmt" <ins> netutil "k8s.io/utils/net" </ins> "os" "runtime" "time"

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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
/sig storage /tirage accepted /assign
Change:
function set-windows-node-image() { WINDOWS_NODE_IMAGE_PROJECT="windows-cloud" if [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win2019" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-2019-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-2019-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win1909" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-1909-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-1909-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win2004" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-2004-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-2004-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION,,}" == "win20h2" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-20h2-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-20h2-dc-core-v20210413" </ins> else echo "Unknown WINDOWS_NODE_OS_DISTRIBUTION ${WINDOWS_NODE_OS_DISTRIBUTION}" >&2 exit 1

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 --Docker is always installed on node boot which adds significant start time and adds software that's unnecessary. containerd Windows nodes should not have Docker installed. Start a Kubernetes GCE Windows cluster via kube-up. You can run stuff like on it. 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 windows /triage accepted