jiebi/CodeConvo huggingface dataset:
Change:
platforms  = flag.String("platform", "", "comma-separated list of platforms to typecheck") timings    = flag.Bool("time", false, "output times taken for each phase") defuses    = flag.Bool("defuse", false, "output defs/uses") <del> serial     = flag.Bool("serial", false, "don't type check platforms in parallel") </del> <ins> serial     = flag.Bool("serial", false, "don't type check platforms in parallel (equivalent to --parallel=1)") parallel   = flag.Int("parallel", 4, "limits how many platforms can be checked in parallel. 0 means no limit.") </ins> skipTest   = flag.Bool("skip-test", false, "don't type check test code") tags       = flag.String("tags", "", "comma-separated list of build tags to apply in addition to go's defaults") ignoreDirs = flag.String("ignore-dirs", "", "comma-separated list of directories to ignore in addition to the default hardcoded list including staging, vendor, and hidden dirs")

Discussion:
Background: We recently introduced Guaranteed Pod QOS on jobs running in GCP project (). Introducing limits on jobs naturally started causing some failures, one of which was (). The original memory limit of caused the pod to be unscheduleable, so it was bumped down to () at which point the pod became scheduleable and the job ran successfully (). At that point, after observing metrics, I mistakenly concluded that this was much higher than needed and suggested bumping down again (). This caused the job to continue to run, but to fail on and sometimes . was recently refactored to not depend on GOPATH (). This was a fairly significant change so I looked at the metrics before and after the rewrite was merged. (June 25th) ! (June 27th) ! Memory usage nearly double for post-merge, which appears to be directly related to the rewrite given that on other branches remained relatively constant. This can be affirmed further by the fact that and are failing with the new resource limits, while older release branches are not. I can see a few options for how we may be able to remedy this issue in the short term: Revert the rewrite to get back to lower (yet still very high) memory usage Separate into a separate job to not reduce signal on the rest of Bump memory limits back up to to get this running successfully again for now I plan to look into fixing up but think it would be a good idea to take one of the directions mentioned above if this cannot be remedied quickly. /priority critical-urgent /sig testing /cc
latest run is green
hmm
Change:
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{

Discussion:
<!-- 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
Change:
} } <del> func TestApplyMultipleObject(t *testing.T) { </del> <ins> func TestApplyMultipleObjectsAsList(t *testing.T) { testApplyMultipleObjects(t, true) } func TestApplyMultipleObjectsAsFiles(t *testing.T) { testApplyMultipleObjects(t, false) } func testApplyMultipleObjects(t *testing.T, asList bool) { </ins> nameRC, currentRC := readAndAnnotateReplicationController(t, filenameRC) pathRC := "/namespaces/test/replicationcontrollers/" + nameRC

Discussion:
kubectl create, delete, etc. can already take a List object. kubectl apply can take the list object when it does creation, but it gives an (ugly) error when it's configuring the objects. Then... expected: Actual:
what's you ?
0-alpha.5
Sounds like a bug. Are you interested in taking a look
sure I will take a look during this weekend.
I think the root cause is , the actually is , in the origin , is not , but after the , this object is nil. Would you like to double check this?
I'll take a look.
if you have make sure about this, please let me know. Thanks :)
Is there any ways we could get this into 1.2? It's actually making our config generation quite painful to have to make a separate file for every object. It looks like got pretty far? would you like to make a PR that we can review?
I don't see how. It could have made 1.2 if a PR had been sent within a few days of the issue being filed.
I unassigned all issues assigned to you. Please only assign issues that are actively being worked on, so that others can know which issues are available to be picked up.
My apologies. If I'm not mistaken, this issue was filed after the code freeze for 1.2. I didn't realize that it was time critical or that it could make the release at that time. However, I should have asked. Sorry for the inconvenience. Thank you. I still plan to address those issues for the next release, as discussed, but will assign each one to myself as I work on it.
I created which fixes this. I'm really hoping we can get this into 1.2 since it's a pretty small, isolated fix but a pretty big bug that is complicating our config generation system. Let me know what else I can do to help.
Thanks for the PR. We're short on reviewer bandwidth at the moment. I assigned it to Clayton for review or delegation.
Change:
} if errors.IsConflict(err) { err = fmt.Errorf(`%v Please review the fields above--they currently have other managers. Here are the ways you can resolve this warning: * If you intend to manage all of these fields, please re-run the apply

Discussion:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc
Change:
// node selectors labels to namespaces var NamespaceNodeSelectors = []string{"scheduler.alpha.kubernetes.io/node-selector"} <ins> var nonTerminalPhaseSelector = func() labels.Selector { var reqs []labels.Requirement for _, phase := range []v1.PodPhase{v1.PodFailed, v1.PodSucceeded} { req, _ := labels.NewRequirement("status.phase", selection.NotEquals, []string{string(phase)}) reqs = append(reqs, *req) } selector := labels.NewSelector() return selector.Add(reqs...) }() </ins> type updateDSFunc func(*appsv1.DaemonSet) // updateDaemonSetWithRetries updates daemonsets with the given applyUpdate func

Discussion:
master-blocking Conformance - GCE - master - kubetest2Kubernetes e2e suite. ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test ! 2023-06-27 16:43 PDT Kubernetes e2e suite: [It] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] No response /sig cloud-provider /sig apps cc
This is more critical than I expected it starts to fail in other jobs ,%20master ,%20ipvs,%20dual,%20master From the diff the best candidate seems can you PTAL /priority critical-urgent
/assign
anyone from you can please add to this issue?
/triage accepted
I have a proposed fix in . Is there a job I can add?
/remove-kind failing-test /kind flake
Change:
import ( "fmt" "net" <ins> "path" </ins> "sync" "time"

Discussion:
/kind bug The lease reconciler creates the kubernetes endpoint with a prefix of kube-apiserver-endpoint, however that is not the prefix that the rest of kube uses. The end result is that the kubernetes service doesn't have an endpoint, and kubectl won't list the kubernetes endpoint. The lease reconciler also creates lease files with a really long lease time instead of the default 15 seconds.
/cc
cc xref
kube-apiserver-endpoint is used for the lease itself, from what I remember. I don't think that's an issue by itself.
Oh but it does look like the endpointRegistry for the lease reconciler is misconfigured to use that
i'll look into it
what is the name that should be used?
services/endpoints afaik -
Yeah, making that change locally fixed it for me
But I'm not seeing the masterleases/apiServerIPInfo data in etcd, or I'm issuing the wrong command to find it
I had that same problem. The lease timeout is set way high, but for some reason that resulted in the lease files being created for only a very short time. I'm not sure why. Playing with the ttl amount got the lease files to stay around....forever. I've got a PR I'm about to push to fix both issues.
FYI has a PR for this now
cc
Change:
configs[Dnsutils] = Config{e2eRegistry, "dnsutils", "1.1"} configs[EchoServer] = Config{e2eRegistry, "echoserver", "2.2"} configs[EntrypointTester] = Config{e2eRegistry, "entrypoint-tester", "1.0"} <del> configs[Etcd] = Config{etcdRegistry, "etcd", "v3.3.10"} </del> <ins> configs[Etcd] = Config{gcRegistry, "etcd", "3.3.10"} </ins> configs[Fakegitserver] = Config{e2eRegistry, "fakegitserver", "1.0"} configs[GBFrontend] = Config{sampleRegistry, "gb-frontend", "v6"} configs[GBRedisSlave] = Config{sampleRegistry, "gb-redisslave", "v3"}

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 see only amd64 architecture etcd is used for the which will create issues for the other architectures like ppc64le, arm etc. We need to replace this etcd image with the k8s maintained fat manifest image present in
/sig testing
Change:
PodDeleteTimeout = 5 * time.Minute ) <del> // DeletePodOrFail deletes the pod of the specified namespace and name. </del> <ins> // DeletePodOrFail deletes the pod of the specified namespace and name. Resilient to the pod // not existing. </ins> func DeletePodOrFail(c clientset.Interface, ns, name string) { ginkgo.By(fmt.Sprintf("Deleting pod %s in namespace %s", name, ns)) err := c.CoreV1().Pods(ns).Delete(context.TODO(), name, metav1.DeleteOptions{}) <ins> if err != nil && apierrors.IsNotFound(err) { return } </ins> expectNoError(err, "failed to delete pod %s in namespace %s", name, ns) }

Discussion:
Which jobs are failing: Which test(s) are failing: Test Overall [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow][LinuxOnly] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority critical-urgent /sig testing /sig storage
This looks like an infrastructure issue but pinging just in case anyone has immediate insight
/remove-kind bug
Looks like recent changes here: /cc
/assign
/reopen unfortunately I don't resolved the issues
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
/assign
how do you say that ? looking at grid - it looks like it is not breaking anymore? Same result with filter applied - There is one failed run after my fix merged - but that is unrelated to original PR and appears to be because of broken cluster: Did I miss anything?
apologies, I believe your fix solved its intended issue, but the job is still failing. I was not clear about that in my comment :+1:
Should this be closed - ? I do not see these tests flaking anymore.
/remove-sig testing /close
Closing this issue. <detailsIn response to : /remove-sig testing /close Instructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Dashboards are green. Wasn't SIG testing
Change:
if [[ ${platform} == "linux/arm" ]]; then export CGO_ENABLED=1 export CC=arm-linux-gnueabi-gcc <ins> # See https://github.com/kubernetes/kubernetes/issues/29904 </ins> export GOROOT=${K8S_PATCHED_GOROOT} elif [[ ${platform} == "linux/arm64" ]]; then export CGO_ENABLED=1

Discussion:
See
CI has built and uploaded unofficial prerelease darwin binaries for 1.4 using go1.7.1: cc Official binaries will ship as soon as we cut 1.4.1.
We have official v1.4.1 binaries available now, too.
Hooray
Change:
defer c.Unlock() if !c.stopped { c.stopped = true <ins> close(c.done) </ins> close(c.input) } }

Discussion:
We noticed many goroutines stalled at in a large cluster (~200 nodes, ~1100 pods). It's because if the WatchServer timeout when the channel is full, will be blocked on the write to the even though is , because WatchServer stops consuming the channel after the timeout.
Great finding - thanks for debugging
Change:
createVolumeConfigMap(config) By("Initializing local volume discovery base path") <del> mkdirCmd := fmt.Sprintf("mkdir %v -m 777", path.Join(hostBase, discoveryDir)) </del> <ins> mkdirCmd := fmt.Sprintf("mkdir -p %v -m 777", path.Join(hostBase, discoveryDir)) </ins> err := framework.IssueSSHCommand(mkdirCmd, framework.TestContext.Provider, config.node0) Expect(err).NotTo(HaveOccurred()) }

Discussion:
The local PV provisioner is being updated to discover only real mount points (and not directories), that resolves some other related issues. The related e2e tests using the local PV provisioner need to be updated accordingly.
/assign
/sig storage
FYI:
Change:
return false } <del> func getServiceTags(service *v1.Service) ([]string, error) { </del> <ins> func getServiceTags(service *v1.Service) []string { if service == nil { return nil } </ins> if serviceTags, found := service.Annotations[ServiceAnnotationAllowedServiceTag]; found { <ins> result := []string{} </ins> tags := strings.Split(strings.TrimSpace(serviceTags), ",") for _, tag := range tags { <del> // Storage and Sql service tags support setting regions with suffix ".Region" if strings.HasPrefix(tag, "Storage.") || strings.HasPrefix(tag, "Sql.") { continue } if !supportedServiceTags.Has(tag) { return nil, fmt.Errorf("only %q are allowed in service tags", supportedServiceTags.List()) </del> <ins> serviceTag := strings.TrimSpace(tag) if serviceTag != "" { result = append(result, serviceTag) </ins> } } <del> return tags, nil </del> <ins> return result </ins> } <del> return nil, nil </del> <ins> return nil </ins> } func serviceOwnsPublicIP(pip *network.PublicIPAddress, clusterName, serviceName string) bool {

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: Azure cloud provider has a limited support for service tags by annotations: But according to , there are actually much more service tags than this list. Hence, errors would happen if the service tag is not included in the above list. What you expected to happen: Azure cloud provider should support all service tags from Azure. How to reproduce it (as minimally and precisely as possible): 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: /kind bug /sig azure /priority important-soon
/assign
Change:
var _ storagelisters.CSINodeLister = CSINodeLister{} // CSINodeLister declares a storagev1.CSINode type for testing. <del> type CSINodeLister storagev1.CSINode </del> <ins> type CSINodeLister []storagev1.CSINode </ins> // Get returns a fake CSINode object. func (n CSINodeLister) Get(name string) (*storagev1.CSINode, error) { <del> csiNode := storagev1.CSINode(n) return &csiNode, nil </del> <ins> for _, cn := range n { if cn.Name == name { return &cn, nil } } return nil, fmt.Errorf("csiNode %q not found", name) </ins> } // List lists all CSINodes in the indexer.

Discussion:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.
Change:
} // create a plugin mgr to load plugins and setup a fake client <del> func newTestWatchPlugin(t *testing.T) (*csiPlugin, *watch.FakeWatcher, string) { </del> <ins> func newTestWatchPlugin(t *testing.T) (*csiPlugin, *watch.RaceFreeFakeWatcher, string) { </ins> tmpDir, err := utiltesting.MkTmpdir("csi-test") if err != nil { t.Fatalf("can't create temp dir: %v", err) } fakeClient := fakeclient.NewSimpleClientset() <del> fakeWatcher := watch.NewFake() </del> <ins> fakeWatcher := watch.NewRaceFreeFake() </ins> fakeClient.Fake.PrependWatchReactor("*", core.DefaultWatchReactor(fakeWatcher, nil)) fakeClient.Fake.WatchReactionChain = fakeClient.Fake.WatchReactionChain[:1] host := volumetest.NewFakeVolumeHost(

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
# managed result of that. Start everything below that directory. log INFO "== Kubernetes addon manager started at $(date -Is) with ADDON_CHECK_INTERVAL_SEC=${ADDON_CHECK_INTERVAL_SEC} ==" <del> # Create the namespace that will be used to host the cluster-level add-ons. start_addon /opt/namespace.yaml 100 10 "" & </del> # Wait for the default service account to be created in the kube-system namespace. token_found="" while [ -z "${token_found}" ]; do

Discussion:
What happened: Add-on manager uses kubectl apply to create the kube-system namespace at start-up. This is redundant because the kube-apiserver creates the namespace in NewBootstrapController. This is a problem because if someone uses apply to make changes to the kube-system namespace, the add-on manager will wipe out these changes. What you expected to happen: Kube-APIServer has the sole responsibility of creating the kube-system namespace. How to reproduce it (as minimally and precisely as possible): kubectl apply a label to the kube-system namespace. restart the add-on manager. Note the labels have been removed. Anything else we need to know?: /sig api-machinery Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
the contention script wipes out namespace ^^
/cc
i guess it is intentional to have the addon manager to ensure kube-system is not modified, it tries to avoid the case that some cluster admin accidentally delete kube-system that result in a non-functional cluster.
The add-on manager will only perform the check when it restarts. The API Server will also perform this check when it restarts. I think we should only have 1 system responsible for this and I believe that system should be the API server.
trying to have my first contribute here, so is it proper to have the kube-system existence checked before applying the yaml file to create the kube-system namespace once again?
The Kube API Server will check for the existence of the kube-system namespace and create it if absent. It does all of this using client-go requests. The Add-On manager is the only system creating the kube-system by applying (a private) yaml file. I believe the correct fix here is to remove the Add-On managers attempts to create the kube-system namespace entirely. This is especially important if a user writes a CI/CD controller to apply their desired state to the kube-system namespace. I would argue the CI/CD is correct but the add-on manager will randomly wipe out the users changes. The API Server on the other hand will not.
, thanks for your help, so i will remove that line and pull a request later
Trying to get my first PR here. Is the issue still open ?
The issue is still open. You may want to check on though as was trying to fix the issue with that PR.