jiebi/CodeConvo huggingface dataset:
Change:
type Server struct { host    HostInterface updates chan<- interface{} <del> handler http.Handler </del> <ins> mux     *http.ServeMux </ins> } <del> func ListenAndServeKubeletServer(host HostInterface, updates chan<- interface{}, delegate http.Handler, address string, port uint) { </del> <ins> // ListenAndServeKubeletServer initializes a server to respond to HTTP network requests on the Kubelet func ListenAndServeKubeletServer(host HostInterface, updates chan<- interface{}, address string, port uint) { </ins> glog.Infof("Starting to listen on %s:%d", address, port) <del> handler := Server{ host:    host, updates: updates, handler: delegate, } </del> <ins> handler := NewServer(host, updates) </ins> s := &http.Server{ Addr:           net.JoinHostPort(address, strconv.FormatUint(uint64(port), 10)), Handler:        &handler,

Discussion:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone
Change:
} // mount it globalPDPath := util.MakeGlobalPDName(*b.fcDisk) <ins> if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } </ins> noMnt, err := b.mounter.IsLikelyNotMountPoint(globalPDPath) if err != nil { return devicePath, fmt.Errorf("Heuristic determination of mount point failed:%v", err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pod creation doesn't finish due to the following error. If the directory doesn't exist it will be created instead of returning error. What you expected to happen: Pod with FC volume works properly. How to reproduce it (as minimally and precisely as possible): Clean up under the "/var/lib/kubelet/plugins" Create a Pod with FC volume Environment: Kubernetes version (use ):Install tools: local-up- /cc
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage
Change:
"testing" "time" <ins> sdktrace "go.opentelemetry.io/otel/sdk/trace" "go.opentelemetry.io/otel/sdk/trace/tracetest" </ins> oteltrace "go.opentelemetry.io/otel/trace" "github.com/golang/mock/gomock"

Discussion:
spans are not being parented to other spans - propagation of context seems broken. More context: spans should be parented to other spans enable kubelet tracing at v1.28 and hook up a tracing backend. No response <detailsv1.28 at least </details<detailsNot sure this matters. </details<details</details<details</details<details</details<details</details
/sig instrumentation /assign
/triage accepted
!
repro steps:
/assign Thanks for helping to look into this! Feel free to post the findings here you shared with me on slack
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <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 will post this ASAP
The broken issue is due to the pr , which try to propagate context brought by pod worker to syncPod function in order to let the syncPod can be interrupted in time by other asynchronous routines, for example eviction. But in the line we did not pass the context which contain the parent span and trace into function, so the trace is broken. So I want to fix this by passing the into , which is also desired in comment But passing the ctx into syncPod may have something other to do as described in comments, so I tried to fix as comments advised.
cc
Change:
for i := 0; i < diff; i++ { go func(ix int) { defer wait.Done() <del> if err := rm.podControl.DeletePod(rc.Namespace, filteredPods[ix].Name); err != nil { </del> <ins> if err := rm.podControl.DeletePod(rc.Namespace, filteredPods[ix].Name, rc); err != nil { </ins> // Decrement the expected number of deletes because the informer won't observe this deletion glog.V(2).Infof("Failed deletion, decrementing expectations for controller %q/%q", rc.Namespace, rc.Name) rm.expectations.DeletionObserved(rcKey)

Discussion:
Currently RC emits an event when it's creating a pod: But nothing is emitted when a pod is deleted. We should create event for scaling both ways. cc
Change:
t.Errorf("%s: Did not get expected path for exec request", test.name) return } <ins> if strings.Count(ex.url.RawQuery, "container=bar") != 1 { t.Errorf("%s: Did not get expected container query param for exec request", test.name) return } </ins> if ex.method != "POST" { t.Errorf("%s: Did not get method for exec request: %s", test.name, ex.method) }

Discussion:
<!-- --What happened: when use command, we found multi query param in the request, because we set the param twice in What you expected to happen: How to reproduce it (as minimally and precisely as possible): use command and set the log level to 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 cli
It seems a duplicate 'container' param are set, thanks for your report. I will fix it later.
Change:
}, timeout: 3 * time.Second, <del> expectedErr: wait.ErrWaitTimeout.Error(), </del> <ins> expectedErr: "timed out waiting for the condition on theresource/name-foo", </ins> validateActions: func(t *testing.T, actions []clienttesting.Action) { if len(actions) != 4 { t.Fatal(spew.Sdump(actions))

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : let's say I run If the deployment is comes up in time it tells me which deployment is up, but if it times out it doesn't tell me on which deployment/resource. Could it be Why is this needed: That would make it easier to use, and the information provided is the same irregardless on whether the condition is met or not
/sig cli
Sounds reasonable for me, i can take care of this one if someone from owners will approve it as a feature.
/assign Zyqsempai
GitHub didn't allow me to assign the following users: Zyqsempai. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Zyqsempai 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:
// Make sure reset happens on patch requests // wait until new webhook is called if err := wait.PollImmediate(time.Millisecond*5, wait.ForeverTestTimeout, func() (bool, error) { <ins> defer recordedWarnings.Reset() </ins> pod, err = client.CoreV1().Pods("default").Patch(context.TODO(), invalidManagedFieldsMarkerFixture.Name, types.JSONPatchType, []byte("[]"), metav1.PatchOptions{}) if err != nil { return false, err

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-integration TestMutatingWebhookResetsInvalidManagedFields Not sure. Example failures from recent PRs: (PR: ) (PR: ) /sig api-machinery /kind flake
There's even a few failures in the post-submit master integration tests job: (ignore the test/integration/job failures, I have an open PR to fix that).
cc
Thanks! /cc /wg api-expression
Oh no, what did I do :-/ I'll have a look. Might be that the admission webhook is not up quick enough. /assign
/triage accepted
I tried this locally and it passes, so maybe I can try stress testing this
Would increasing the timelimit here give more time to the admissionhook to come up ?
I think so. Looked at it a few days ago, I'm not sure how much we should increase it. I don't want to slow down the tests a lot more if we can avoid it. Do we know if the other admission tests (duplicate owner ref) have the same issue?
Can we make the webhook blocking so that the request will wait for it to be ready? Can we make sure that it's up-and-running somehow before performing the actual test? Having an arbitrary "wait" before we start the test seems wrong.
The poll and timeout are fine as is. lastErr is only getting set, never unset. If validateManagedFieldsAndDecode returns nil, lastErr should get cleared.
Hmm.. actually, the one failing is the Update request, after the Patch request has already been checked. The patch request passing means the webhook was effective and working, the update request should work consistently the first time. If the patch request really is ensuring the webhook was installed, then a timeout or retry on the update request is not the right approach.
But isnt the patch request alos failing to report the adequate warnings
this continues to be the flakiest test in the integration job in by a wide margin
So sorry for letting this slip for so long :-/ I'll work on it right when I get back home in an hour.
Change:
cidrUpdateRetries = 3 // updateRetryTimeout is the time to wait before requeing a failed node for retry <del> updateRetryTimeout = 100 * time.Millisecond </del> <ins> updateRetryTimeout = 250 * time.Millisecond // maxUpdateRetryTimeout is the maximum amount of time between timeouts. maxUpdateRetryTimeout = 5 * time.Second </ins> // updateMaxRetries is the max retries for a failed node updateMaxRetries = 10

Discussion:
/kind bug /sig network What happened: Networking tight loop causing GCP Cloud rate limiting to kick in. Causing tests to fail. Suspected call stack: Looks like it could be the root cause of these test failures here: https://k8s- These storage tests are hitting rate limit on the cloud api when trying to detach/delete disks. However, we have exponential backoff for all these functions. But the rate limiting from an external source is affecting the tests. See logs snippet: Note: These logs span exactly 1 minute. Try grepping "rateLimit" or "CIDRNotAvailable" -also note that the CIDRNotAvailable error messages are probably not verbose enough as they do not pinpoint what the actual error is, you can only associate them by correlation in timing and then looking at the code. Shorter snippet from above log file to demonstrate: since this is running on hundreds of nodes hitting this API call should involve some sort of exponential backoff as well as jitter. /cc /assign
/assign
/assign
/sig cloud-provider /sig gcp /milestone v1.12 (since is marked as v1.12)
may we have a priority on this since Code Freeze is next week? :)
Quick question, are we using the default API rate limits quota for scalability projects?
I will defer to for priority because he probably has the most context on how serious this is and what it could affect
Which rate limit are you referring to? (I don't remember us changing it any time) Btw - this is the project being used for that job -
I put up a patch for adding exponential retry
Gentle reminder that for this to be considered for 1.12 past Code Freeze, which is next week, it must have a status/critical-urgent label. I see this is being actively worked on
Change:
// Returns a cache.ListWatch that gets all changes to services. func createServiceLW(kubeClient *kclient.Client) *kcache.ListWatch { <del> return kcache.NewListWatchFromClient(kubeClient, "services", kapi.NamespaceAll, kSelector.Everything()) </del> <ins> return kcache.NewListWatchFromClient(kubeClient, "services", kapi.NamespaceAll, kselector.Everything()) </ins> } // Returns a cache.ListWatch that gets all changes to endpoints. func createEndpointsLW(kubeClient *kclient.Client) *kcache.ListWatch { <del> return kcache.NewListWatchFromClient(kubeClient, "endpoints", kapi.NamespaceAll, kSelector.Everything()) </del> <ins> return kcache.NewListWatchFromClient(kubeClient, "endpoints", kapi.NamespaceAll, kselector.Everything()) </ins> } // Returns a cache.ListWatch that gets all changes to pods. func createEndpointsPodLW(kubeClient *kclient.Client) *kcache.ListWatch { <del> return kcache.NewListWatchFromClient(kubeClient, "pods", kapi.NamespaceAll, kSelector.Everything()) </del> <ins> return kcache.NewListWatchFromClient(kubeClient, "pods", kapi.NamespaceAll, kselector.Everything()) </ins> } func (ks *kube2sky) newService(obj interface{}) {

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
// any fields that are currently set. // TODO(madhusudancs): Simplify the logic for setting node conditions and // refactor the node status condition code out to a different file. <del> func (kl *Kubelet) setNodeStatus(node *v1.Node) error { </del> <ins> func (kl *Kubelet) setNodeStatus(node *v1.Node) { </ins> for _, f := range kl.setNodeStatusFuncs { if err := f(node); err != nil { <del> return err </del> <ins> glog.Warningf("Failed to set some node status fields: %s", err) </ins> } } <del> return nil </del> } // defaultNodeStatusFuncs is a factory that generates the default set of

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 1.3.8 custom build - the code seems to still be in place in master. Environment: Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): VERSION="14.04.5 LTS, Trusty Tahr" Kernel (e.g. ): 4.4.0-38-generic ~14.04.1-Ubuntu SMP Tue Sep 6 17:20:43 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: Custom Others: What happened: When the OpenStack Nova API is not accessible Nodes are marked as "NotReady" The OpenStack cloud providers seems to call Nova on a schedule to get information. If the API is not contactable, kubelet fails to call back to the masters, and gets marked as NotReady. Masters also call the Nova API, and when it fails, it can mark all nodes as NotReady. What you expected to happen: Nothing - the cluster should still work, regardless of Nova's API How to reproduce it (as minimally and precisely as possible): Install Kubernetes using the OpenStack provider. On the OpenStack controller stop the nova-api process.
Change:
streamingServer    streaming.Server networkPlugin      network.NetworkPlugin containerManager   cm.ContainerManager <ins> // cgroup driver used by Docker runtime. cgroupDriver string </ins> } // Version returns the runtime name, runtime version and runtime API version

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
const ( aggregatorServicePort = 7443 <ins> apiServiceRetryPeriod  = 1 * time.Second apiServiceRetryTimeout = 1 * time.Minute </ins> ) var _ = SIGDescribe("Aggregator", func() {

Discussion:
[X] Test approval issue: [X] Test PR: 7 July 2022 [x] Two weeks soak end date: 21 Jul 2022 [x] Test promotion According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. replaceApiregistrationV1APIServiceStatuspatchApiregistrationV1APIServiceStatusreplaceApiregistrationV1APIServicedeleteApiregistrationV1CollectionAPIService Using a number of existing e2e test practices a new has been created for 4 APIService endpoints. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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:
return false, errors.Errorf("%s is not a known certificate", name) } <del> return handler.readwriter.Exists(), nil </del> <ins> return handler.readwriter.Exists() </ins> } // GetCertificateExpirationInfo returns certificate expiration info.

Discussion:
When the command is run with superuser privileges, it prints the requested information. Print a warning that files could not be read due to insufficient permission, or that information was missing (e.g., when the /etc/kubernetes directory is not initialized). When the directory is readable, it works as expected: where OS and kubeadm version detail was: Issue the command as a normal user when the directory /etc/kubernetes/pki exists but not readable. No response <details</details<detailsBare metal </details<details</details<detailsapt-get install kubeadm (source repo: ) </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 cluster-lifecycle
Change:
return 100 * time.Millisecond } <del> idleSuccess := make(chan struct{}) fw.fakeKubelet.portForwardFunc = func(name string, uid types.UID, port uint16, stream io.ReadWriteCloser) error { select { case <-idleSuccess: case <-time.After(150 * time.Millisecond): t.Fatalf("execFunc timed out waiting for idle timeout") } return nil } </del> podNamespace := "other" podName := "foo"

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
"net" "os" "path/filepath" <ins> "strconv" </ins> "strings" "k8s.io/api/core/v1"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: For IPv6, the node CIDR size is hard coded to /64. This causes an error bringing up the kube-controller, as the size must be for a smaller subnet (larger value) that what is used for the pod subnet, which is specified for some CNI plugins (e.g. Calico). In addition, this is a catch-22, as the pod subnet prefix cannot be for a larger network (smaller value) than /66, so we cannot set it to /63, for example. What you expected to happen: The node CIDR size should be computed, based on the pod subnet specified, so that it can meet the requirements. How to reproduce it (as minimally and precisely as possible): Bring up a cluster using KubeAdm, specifying IPv6 and choose any pod subnet prefix desired. Anything else we need to know?: Note, there is a second requirement, that the difference between pod subnet size and node CIDR size be 16 or less (issue ). I'll be submitting a proposed PR to address this. Environment: Kubernetes version (use ): latest on master, using 1.9.2 in my case Cloud provider or hardware configuration: bare metal, single node OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux bxb-c2-77 4.4.0-109-generic -Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: /area ipv6 /sig network
/assign pmichali