jiebi/CodeConvo huggingface dataset:
Change:
[sig-apps] Daemon set [Serial] should retry creating failed daemon pods [Conformance] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] [sig-apps] Daemon set [Serial] should run and stop complex daemon [Conformance] [sig-apps] Daemon set [Serial] should run and stop simple daemon [Conformance] [sig-apps] Daemon set [Serial] should update pod when spec was updated and update strategy is RollingUpdate [Conformance] Please see: https://k8s-,%20master%20(dev) https://k8s-,%20master%20(dev)
can you please take a look? I see at least one change in this range that probably caused this?
/sig apps /priority failing-test
/milestone v1.11
/kind bug /priority critical-urgent
cc
thanks for tracking and opening this issue.
cc and
These tests are also failing in sig-release-master-blocking kubeadm-gce jobs https://k8s- This is release blocking as we are entering Code slush on Tuesday 5/29.
cc
Fix in
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details

Discussion:
return *typed.Spec.Replicas, nil } return 0, nil <ins> case *extensions.DaemonSet: return 0, nil </ins> case *batch.Job: // TODO: currently we use pause pods so that's OK. When we'll want to switch to Pods // that actually finish we need a better way to do this.
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug We can see all related with test failed. and so on. I think it maybe relate with PR and . What happened: Always fails. What you expected to happen: Pass all.
/cc PTAL. Thanks.
Why did the not pass the test but was still merged?
/priority important-soon /kind e2e-test-failure
/area platform/gce
Looks like the fix is in
is not a blocking / required test (for merge) currently IIRC, kubernetes/kubernetes uses the "submit-queue" which will only pay attention to some tests.
i think this is true, as confirmed by the current state of this PR: it fails the test, but the CI says instead of is there are way to see which tests would cause a ?
off the top of my head the definitive way is this list: but note that is working on moving us to in the nearish future, and every other kubernetes repo besides this one is either not using merge automation or is using , which behaves differently and has seperate config integrated with the rest of test-infra.
thanks for the details! :+1:

Discussion:
visibility = ["//visibility:public"], deps = [ "//pkg/api/v1/pod:go_default_library", <del> "//pkg/apis/apps:go_default_library", </del> "//pkg/apis/core:go_default_library", <ins> "//pkg/apis/extensions:go_default_library", </ins> "//pkg/apis/scheduling:go_default_library", "//pkg/kubelet/apis:go_default_library", "//pkg/quota/evaluator/core:go_default_library",

"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <del> "k8s.io/kubernetes/pkg/apis/apps" </del> <ins> extensionsinternal "k8s.io/kubernetes/pkg/apis/extensions" </ins> "k8s.io/kubernetes/test/e2e/framework" imageutils "k8s.io/kubernetes/test/utils/image"

framework.ExpectNoError(err, "failed to create nvidia-driver-installer daemonset") framework.Logf("Successfully created daemonset to install Nvidia drivers.") <del> pods, err := framework.WaitForControlledPods(f.ClientSet, ds.Namespace, ds.Name, apps.Kind("DaemonSet")) </del> <ins> pods, err := framework.WaitForControlledPods(f.ClientSet, ds.Namespace, ds.Name, extensionsinternal.Kind("DaemonSet")) </ins> framework.ExpectNoError(err, "failed to get pods controlled by the nvidia-driver-installer daemonset") <del> devicepluginPods, err := framework.WaitForControlledPods(f.ClientSet, "kube-system", "nvidia-gpu-device-plugin", apps.Kind("DaemonSet")) </del> <ins> devicepluginPods, err := framework.WaitForControlledPods(f.ClientSet, "kube-system", "nvidia-gpu-device-plugin", extensionsinternal.Kind("DaemonSet")) </ins> if err == nil { framework.Logf("Adding deviceplugin addon pod.") pods.Items = append(pods.Items, devicepluginPods.Items...)
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Looks like the newly tests are failing: https://k8s-
/assign Also random question to why is the same test run 4 times?
GitHub didn't allow me to assign the following users: kevtaylor. Note that only and repo collaborators 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
cc
can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally
Reiterating the mentions to trigger a notification: <detailsIn response to : can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally 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
I suggest unless anyone can define why the events do not appear, we disable that part of the test and just check for error. If you are okay with that please reopen the bug and I'll put in a new fix
it looks like node alpha suite is having some other issues right now that are preventing the tests from being run. So it's not clear right now if the fix helped or not.
it failed again. I did a comparison of a locally running one and the alpha suite. In the log file https://k8s- there are these references But in the locally running tests I don't see that step This running And the events running locally
/reopen

Discussion:
. "github.com/onsi/ginkgo" . "github.com/onsi/gomega" <del> "time" </del> ) // These tests exercise the Kubernetes expansion syntax $(VAR).

framework.DeletePodWithWait(f, f.ClientSet, pod) }() <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, 30*time.Second) </del> <ins> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </ins> Expect(err).To(HaveOccurred(), "while waiting for pod to be running") selector := fields.Set{
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /assign What happened: Here's some failures https://k8s- https://k8s-
/assign
More recent failures from https://k8s- https://k8s- https://k8s- https://k8s-
I submitted a PR to fix recent PVAssumeCache.Assume out-of-sync failures:
I wonder if this could be the same issue as
Not sure yet, but there are some other flakes: https://k8s- https://k8s- https://k8s- I'll keep tracking this issue. /reopen
Oh, my mistake, these are failures tests of when PR is not completed. /close

Discussion:
func (c *configFactory) invalidatePredicatesForPvUpdate(oldPV, newPV *v1.PersistentVolume) { invalidPredicates := sets.NewString() <ins> // CheckVolumeBinding predicate calls SchedulerVolumeBinder.FindPodVolumes // which will cache PVs in PodBindingCache. When PV got updated, we should // invalidate cache, otherwise PVAssumeCache.Assume will fail with out of sync // error. invalidPredicates.Insert(predicates.CheckVolumeBindingPred) </ins> for k, v := range newPV.Labels { // If PV update modifies the zone/region labels. if isZoneRegionLabel(k) && !reflect.DeepEqual(v, oldPV.Labels[k]) {
Change:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: Created a service of type on Azure. The service is created successful and a LoadBalancer with public IP is created on Azure. kube-controller-manager goes into a crashloop What you expected to happen: LoadBalancer service receives public IP and is available for traffic How to reproduce it (as minimally and precisely as possible): provision a loadbalancer service on Azure with v1.10.3. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig api-machinery /sig azure
Logs of the initial request to create the load balancer service:
/remove-sig api-machinery
fyi
FYI
BTW, this is with an Availability Set.
Update: my was missing: Once I it LoadBalancer services work. Still, we shouldn't panic in the main loop on this.
Thanks I think we can close this issue. Create another for handling errors in both the cloud provider and the controller.
/cc
/assign
Filed to fix this

Discussion:
// update security rules dirtySg := false var updatedRules []network.SecurityRule <del> if sg.SecurityRules != nil { updatedRules = *sg.SecurityRules </del> <ins> if sg.SecurityGroupPropertiesFormat != nil && sg.SecurityGroupPropertiesFormat.SecurityRules != nil { updatedRules = *sg.SecurityGroupPropertiesFormat.SecurityRules </ins> } for _, r := range updatedRules {

} func (az *Cloud) getSecurityGroup() (nsg network.SecurityGroup, err error) { <ins> if az.SecurityGroupName == "" { return nsg, fmt.Errorf("securityGroupName is not configured") } </ins> securityGroup, err := az.nsgCache.Get(az.SecurityGroupName) if err != nil { return nsg, err
Change:
/kind feature Can we provide a way to enable etcd clientv3 prometheus metrics at the apiserver side ? The etcd.clientv3 interface is instantiated and it does not enable metrics. In file in coreos/etcd, one can see the to pass to enable metrics. It would be great if the apiserver has a command line parameter, config/environment variable to enable etcd.clientv3 metrics.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
This issue is quite similar to
Yes, this is a good idea, in fact we just released a new version of the package required for this.
/assign
I can do it.
oh, maybe I should use the new features to implement, I will continue to modify it.
are you referring to injecting the registry to use? Yes I would very much appreciate that, even if we (for now) inject the , that will allow us to modify that more easily in the future.

Discussion:
"//vendor/github.com/coreos/etcd/client:go_default_library", "//vendor/github.com/coreos/etcd/clientv3:go_default_library", "//vendor/github.com/coreos/etcd/pkg/transport:go_default_library", <ins> "//vendor/github.com/grpc-ecosystem/go-grpc-prometheus:go_default_library", "//vendor/google.golang.org/grpc:go_default_library", </ins> ], )

"github.com/coreos/etcd/clientv3" "github.com/coreos/etcd/pkg/transport" <ins> grpcprom "github.com/grpc-ecosystem/go-grpc-prometheus" "google.golang.org/grpc" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apiserver/pkg/storage"

DialTimeout:          dialTimeout, DialKeepAliveTime:    keepaliveTime, DialKeepAliveTimeout: keepaliveTimeout, <del> Endpoints:            c.ServerList, TLS:                  tlsConfig, </del> <ins> DialOptions: []grpc.DialOption{ grpc.WithUnaryInterceptor(grpcprom.UnaryClientInterceptor), grpc.WithStreamInterceptor(grpcprom.StreamClientInterceptor), }, Endpoints: c.ServerList, TLS:       tlsConfig, </ins> } client, err := clientv3.New(cfg) return client, err

"Rev": "787624de3eb7bd915c329cba748687a3b22666a6" }, { <ins> "ImportPath": "github.com/grpc-ecosystem/go-grpc-prometheus", "Rev": "2500245aa6110c562d17020fb31a2c133d737799" }, { </ins> "ImportPath": "github.com/hashicorp/golang-lru", "Rev": "a0d98a5f288019575c6d1f4bb1573fef2d1fcdc4" },
Change:
Error Logs /kind bug /priority failing-test /priority critical-urgent /milestone v1.11 /assign cc Possible breaking change as per offline discussions.
- Timeline of breakage aligns with merge of , nothing else was in flight to cause it.
could this be the problem?
Is that's the problem, may be this will help
/sig cluster-lifecycle
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
you can't re-open an issue/PR unless you authored it or you are assigned to it. <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
https://k8s- https://k8s- both jobs are better now (past the failure where they keeled over before the test suite started). But both seem to have some test failures
we have one green run on each, so let's close this out. https://k8s- https://k8s- /close

Discussion:
import ( "fmt" "io/ioutil" <ins> "os" </ins> "path/filepath" "k8s.io/api/core/v1"

configFile := filepath.Join(kubeletDir, kubeadmconstants.KubeletConfigurationFileName) fmt.Printf("[kubelet] Writing kubelet configuration to file %qn", configFile) <ins> // creates target folder if not already exists if err := os.MkdirAll(kubeletDir, 0700); err != nil { return fmt.Errorf("failed to create directory %q: %v", kubeletDir, err) } </ins> if err := ioutil.WriteFile(configFile, b, 0644); err != nil { return fmt.Errorf("failed to write kubelet configuration to the file %q: %v", configFile, err) }
Change:
brought this up during the CSI Standup. It seems to be true, in the test config we do not set which is required to bring up the pod for consuming the volume. The code where is checked: The test config used where is not set to true: /kind bug /sig storage /assign /cc

Discussion:
attach, err := c.k8s.StorageV1beta1().VolumeAttachments().Get(attachID, meta.GetOptions{}) if err != nil { glog.Error(log("attacher.WaitForAttach failed for volume [%s] (will continue to try): %v", volumeHandle, err)) <del> return "", err </del> <ins> return "", fmt.Errorf("volume %v has GET error for volume attachment %v: %v", volumeHandle, attachID, err) </ins> } // if being deleted, fail fast if attach.GetDeletionTimestamp() != nil {

claimSize:    "1Gi", expectedSize: "1Gi", nodeName:     node.Name, <ins> attach:       true, </ins> } }

claimSize:    "5Gi", expectedSize: "5Gi", nodeName:     node.Name, <ins> attach:       true, </ins> } }
Change:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: Currently the vsphere cloud provider blocks the controller-manager from running if its running on a non-vmware host, because it reads and checks if its content starts with . What you expected to happen: The controller manager to start How to reproduce it (as minimally and precisely as possible): Start a on a non-vmware environment with the flags set Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig vmware
can you please share some more context- Why do you want vSphere cloud provider to work with non-vmware host (I believe you mean ESXi)? Where is this requirement coming from.
We are building a Kubernetes cluster management solution which does Kubernetes in Kubernetes and works by creating the control planes in one cluster, then creating worker instances on one of the supported platforms, among them vsphere. Currently the cluster hosting the control planes (We call it seed cluster) has to run on ESXi, otherwise the controller-manager crashes. Having the check in place for the Kubelets is completely fine and definitely makes sense, but for the controller-manager it should IMHO not be required.

Discussion:
WorkingDir string `gcfg:"working-dir"` // Soap round tripper count (retries = RoundTripper - 1) RoundTripperCount uint `gcfg:"soap-roundtrip-count"` <del> // Deprecated as the virtual machines will be automatically discovered. </del> <ins> // Is required on the controller-manager if it does not run on a VMware machine </ins> // VMUUID is the VM Instance UUID of virtual machine which can be retrieved from instanceUuid // property in VmConfigInfo, or also set as vc.uuid in VMX file. // If not set, will be fetched from the machine via sysfs (requires root)

glog.Errorf("Failed to get hostname. err: %+v", err) return nil, err } <del> vs.vmUUID, err = getVMUUID() if err != nil { glog.Errorf("Failed to get uuid. err: %+v", err) return nil, err </del> <ins> if cfg.Global.VMUUID != "" { vs.vmUUID = cfg.Global.VMUUID } else { vs.vmUUID, err = getVMUUID() if err != nil { glog.Errorf("Failed to get uuid. err: %+v", err) return nil, err } </ins> } runtime.SetFinalizer(vs, logout) return vs, nil
Change:
/kind bug What happened: does not show the description for the new field in What you expected to happen: should describe the new field. How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version (use ): master
/sig auth
GitHub didn't allow me to assign the following users: fanzhangio. Note that only and repo collaborators 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
If nobody has started yet, I wanna to pick it up.
was working on it AFAIR.
Indeed. if you don't mind, I'd take over.

Discussion:
if len(psp.Spec.AllowedFlexVolumes) > 0 { w.Write(LEVEL_1, "Allowed FlexVolume Types:t%sn", flexVolumesToString(psp.Spec.AllowedFlexVolumes)) } <ins> if len(psp.Spec.AllowedUnsafeSysctls) > 0 { w.Write(LEVEL_1, "Allowed Unsafe Sysctls:t%sn", sysctlsToString(psp.Spec.AllowedUnsafeSysctls)) } if len(psp.Spec.ForbiddenSysctls) > 0 { w.Write(LEVEL_1, "Forbidden Sysctls:t%sn", sysctlsToString(psp.Spec.ForbiddenSysctls)) } </ins> w.Write(LEVEL_1, "Allow Host Network:t%tn", psp.Spec.HostNetwork) w.Write(LEVEL_1, "Allow Host Ports:t%sn", hostPortRangeToString(psp.Spec.HostPorts)) w.Write(LEVEL_1, "Allow Host PID:t%tn", psp.Spec.HostPID)

return stringOrDefaultValue(strings.Join(volumes, ","), "<all>") } <ins> func sysctlsToString(sysctls []string) string { return stringOrNone(strings.Join(sysctls, ",")) } </ins> func hostPortRangeToString(ranges []policy.HostPortRange) string { formattedString := "" if ranges != nil {

"Required Drop Capabilities:s*<none>", "Allowed Capabilities:s*<none>", "Allowed Volume Types:s*<none>", <ins> "Allowed Unsafe Sysctls:s*kernel.*,net.ipv4.ip_local_port_range", "Forbidden Sysctls:s*net.ipv4.ip_default_ttl", </ins> "Allow Host Network:s*false", "Allow Host Ports:s*<none>", "Allow Host PID:s*false",

Name: "mypsp", }, Spec: policy.PodSecurityPolicySpec{ <ins> AllowedUnsafeSysctls: []string{"kernel.*", "net.ipv4.ip_local_port_range"}, ForbiddenSysctls:     []string{"net.ipv4.ip_default_ttl"}, </ins> SELinux: policy.SELinuxStrategyOptions{ Rule: policy.SELinuxStrategyRunAsAny, },
Change:
What happened: is a subdirectory of the btrfs subvolume . kubelet fails to start with the following error: What you expected to happen: kubelet starts normally and doesn't fail with an error message How to reproduce it (as minimally and precisely as possible): Install a system using btrfs as file system for / Create a sub-volume for /var Start kubelet (even in disconnected mode) Anything else we need to know?: This is a follow-up issue of and has been promoted to fatal from onward, before it was a warning PR to fix the issue is Environment: Kubernetes version (use ): forward Cloud provider or hardware configuration: both bare metal and virtual OS (e.g. from /etc/os-release): SUSE 12+ or openSUSE (Tumbleweed/Leap) Kernel (e.g. ): Install tools: SUSE/openSUSE rpm Others:
/sig storage
fixed by /close
If I may - adding some notes - it might be helpful for others, until I get the time to do some more detailed tests and report a bug. I still had issues with kubelet not starting, with the same error - (version 1.13.4) My btrfs setup is that btrfs root is mounted at /, then I have also a subvolume /var and in it a subvolume /var/lib. The issue for me I think comes from the fact that I do not have a flat btrfs setup () but a nested one, and as such, I have as a mountpoint ONLY the root directory. Manually adding a mount entry for /var (heh - I should probably have mounted /var/lib) in /etc/fstab made it work: /var btrfs rw,relatime,ssd,space_cache,subvolid=259,subvol=/var 0 0` Also, even without this additional "intermediate" mount point I think it should have been working. I wonder if in , the loop 'for !found {' isn't exiting a tiny bit too fast (without testing for the root mountpoint itself) . Maybe it should be something like:
Has something changed in the code? Kubelet from kubernetes 1.20.1 is failing. Doing a mount as I described above fixes it.
see (open) and (closed) - apparently this was recently fixed (but isn't released yet).

Discussion:
sleep 5 <del> POD_LIST_1=$($KUBECFG '-template={{range.Items}}{{.Meta}} {{end}}' list pods) </del> <ins> POD_LIST_1=$($KUBECFG '-template={{range.Items}}{{.Name}} {{end}}' list pods) </ins> echo "Pods running: ${POD_LIST_1}" $KUBECFG stop redisSlaveController

$KUBECFG delete services/redismaster $KUBECFG delete pods/redis-master-2 <del> POD_LIST_2=$($KUBECFG '-template={{range.Items}}{{.Meta}} {{end}}' list pods) </del> <ins> POD_LIST_2=$($KUBECFG '-template={{range.Items}}{{.Name}} {{end}}' list pods) </ins> echo "Pods running after shutdown: ${POD_LIST_2}" exit 0
Change:
We're seeing an issue with large memory growth in NoExecuteTaintManager when pods with tolerations are rapidly created/deleted. The item to the workqueue contains the full pod objects received from the informer: That means those pod objects are retained until they are processed. Additionally, it looks like the processing loop never removed the keys from the workqueue when it was done. It also means that multiple updates for the same pod result in multiple items in the workqueue, rather than enqueuing the pod to be processed once, like other controllers do. Simplifying this controller to enqueue pod updates only by name/namespace, and operate on the latest pod obtained from the store (like other controllers do) would speed up the processing and relieve the memory burden of the workqueue. /sig scheduling /cc
/assign
Thanks for finding this Jordan - looking into your fixes.
the memory issue was fixed by /close

Discussion:
hash := hash(nodeUpdate.name()) select { case <-stopCh: <ins> tc.nodeUpdateQueue.Done(item) </ins> break case tc.nodeUpdateChannels[hash%workers] <- nodeUpdate: } <ins> tc.nodeUpdateQueue.Done(item) </ins> } }(stopCh)

hash := hash(podUpdate.nodeName()) select { case <-stopCh: <ins> tc.podUpdateQueue.Done(item) </ins> break case tc.podUpdateChannels[hash%workers] <- podUpdate: } <ins> tc.podUpdateQueue.Done(item) </ins> } }(stopCh)