jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/kubernetes/pkg/util/intstr" ) <del> // TODO(phase1+): kube-proxy should be a daemonset, three different daemonsets should not be here func createKubeProxyPodSpec(cfg *kubeadmapi.MasterConfiguration, architecture string) api.PodSpec { </del> <ins> func createKubeProxyPodSpec(cfg *kubeadmapi.MasterConfiguration) api.PodSpec { </ins> envParams := kubeadmapi.GetEnvParams() privilegedTrue := true return api.PodSpec{ SecurityContext: &api.PodSecurityContext{HostNetwork: true}, <del> NodeSelector: map[string]string{ "beta.kubernetes.io/arch": architecture, }, </del> Containers: []api.Container{{ Name:            kubeProxy, Image:           images.GetCoreImage(images.KubeProxyImage, cfg, envParams["hyperkube_image"]),

Discussion:
Right now we create 3 daemonsets for in , but will only give use image names for , so this feature is broken. We should only deploy one daemon set for the native architecture, but ensure it has the right label selectors, so we don't try to run pods on nodes of different architecture. We should also make sure all addons have architecture labels, and not just . If user is building heterogeneous clusters, the will need to take about deploying addons for additional architectures, we shouldn't pre-deploy multiple things knowing that they will most likely remain unschedulable.
I have the same issue as well. I tried to create a cluster with x86 (Intel NUC) and arm (Raspberry-Pi) and I see that the kube-proxy is crashing. Here's the log entry from kube-proxy Logs from kube-proxy exec user process caused "exec format error" Attached is the kube-proxy yaml file. I see that its picking up arm image Don't know how to fix this.
Change:
testReadFile(input.f, input.filePathInSubpath, input.pod, 0) }) <ins> It("should verify container cannot write to subpath readonly volumes", func() { if input.roVol == nil { framework.Skipf("Volume type %v doesn't support readOnly source", input.volType) } // Format the volume while it's writable formatVolume(input.f, input.formatPod) // Set volume source to read only input.pod.Spec.Volumes[0].VolumeSource = *input.roVol // Write the file in the volume from container 0 setWriteCommand(input.subPathDir, &input.pod.Spec.Containers[0]) // Pod should fail testPodFailSubpath(input.f, input.pod, true) }) </ins> // TODO: add a test case for the same disk with two partitions }

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: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!
Change:
"k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" <del> "k8s.io/apimachinery/pkg/util/wait" </del> "k8s.io/apimachinery/pkg/watch" "k8s.io/cli-runtime/pkg/genericclioptions" "k8s.io/cli-runtime/pkg/genericclioptions/printers"

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:
// request's context's Done channel gets closed by the time // the request is done being processed. doneCh := ctx.Done() <ins> // Retrieve the queueset configuration name while we have the lock // and use it in the goroutine below. configName := qs.qCfg.Name </ins> if doneCh != nil { qs.preCreateOrUnblockGoroutine() go func() {

Discussion:
Which jobs are flaking: ci-kubernetes-cached-make-test ci-kubernetes-generate-make-test-count10 pull-kubernetes-unit Which test(s) are flaking: TestPriorityAndFairnessWithPanicRecoveryAndTimeoutFilter Testgrid link: Reason for failure: Data race: Reproduced in ~2% of runs with : Triage board: /sig api-machinery
cc
The test is timing out after 300 seconds, but I couldn't reproduce this over 1000 runs (with and without )
(In case it's not clear from comments: the actual failure is the timeout, not the panic as stated in the OP.)
Finally reproduced the issue locally after many runs:
thank you for reproducing it! are you planning to try to fix it? Thanks!
I tried to, but I couldn't find the root cause. I'll take another look today. /assign
/accept triage
/triage accepted
/milestone v1.21 /priority critical-urgent Raising priority and adding to the milestone for triage since this looks like a data race in non-test code in a default-enabled filter. This unit test did not exist in 1.20 so it's not clear if this is a regression in 1.21 or not. If this issue existed in 1.20, priority can be lowered to important-soon and it does not block 1.21, but should be fixed and picked to 1.20.x and 1.21.x
I'm afraid I won't have the time to look into this in the short term. Unassigning so that someone else can take a look. /unassign
(looking at it now) /assign
found the data race and put out a quick fix for this:
I ran , and it looks good so far:
cherry-picked it for - Can someone please let me know if I did it correctly?
Change:
// Apply cgroupsParent derived from the sandbox config. if lc := sandboxConfig.GetLinux(); lc != nil { // Apply Cgroup options. <del> // TODO: Check if this works with per-pod cgroups. // TODO: we need to pass the cgroup in syntax expected by cgroup driver but shim does not use docker info yet... hc.CgroupParent = lc.GetCgroupParent() </del> <ins> cgroupParent, err := ds.GenerateExpectedCgroupParent(lc.GetCgroupParent()) if err != nil { return "", fmt.Errorf("failed to generate cgroup parent in expected syntax for container %q: %v", config.Metadata.GetName(), err) } hc.CgroupParent = cgroupParent </ins> } // Set devices for container.

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:
return false, nil } <ins> if wantPrefixForEncryptAll != "" { deploymentName := fmt.Sprintf("deployment-%d", idx) _, err := test.createDeployment(deploymentName, "default") if err != nil { t.Fatalf("Failed to create test secret, error: %v", err) } rawEnvelope, err := test.readRawRecordFromETCD(test.getETCDPathForResource(test.storageConfig.Prefix, "", "deployments", deploymentName, "default")) if err != nil { t.Fatalf("failed to read %s from etcd: %v", test.getETCDPathForResource(test.storageConfig.Prefix, "", "deployments", deploymentName, "default"), err) } // check prefix if !bytes.HasPrefix(rawEnvelope.Kvs[0].Value, []byte(wantPrefixForEncryptAll)) { idx++ swapErr = fmt.Errorf("expected deployment to be prefixed with %s, but got %s", wantPrefixForEncryptAll, rawEnvelope.Kvs[0].Value) // return nil error to continue polling till timeout return false, nil } } </ins> return true, nil }) if pollErr == wait.ErrWaitTimeout {

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:
resourceGroup := matches[1] return strings.Replace(resourceID, resourceGroup, strings.ToLower(resourceGroup), 1), nil } <ins> // isBackendPoolOnSameLB checks whether newBackendPoolID is on the same load balancer as existingBackendPools. // Since both public and internal LBs are supported, lbName and lbName-internal are treated as same. // If not same, the lbName for existingBackendPools would also be returned. func isBackendPoolOnSameLB(newBackendPoolID string, existingBackendPools []string) (bool, string, error) { matches := backendPoolIDRE.FindStringSubmatch(newBackendPoolID) if len(matches) != 2 { return false, "", fmt.Errorf("new backendPoolID %q is in wrong format", newBackendPoolID) } newLBName := matches[1] newLBNameTrimmed := strings.TrimRight(newLBName, InternalLoadBalancerNameSuffix) for _, backendPool := range existingBackendPools { matches := backendPoolIDRE.FindStringSubmatch(backendPool) if len(matches) != 2 { return false, "", fmt.Errorf("existing backendPoolID %q is in wrong format", backendPool) } lbName := matches[1] if !strings.EqualFold(strings.TrimRight(lbName, InternalLoadBalancerNameSuffix), newLBNameTrimmed) { return false, lbName, nil } } return true, "", nil } </ins>

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: SLB backend pools are empty if outbound rules are defined in a separate backend pool. This is because, although we the check for not adding the backend pools from different LBs, the lbName is not checked: The new backend pool's lbName should be also checked in above codes. What you expected to happen: SLB backend pools should be updated correctly when outbound rules are defined in a separate backend pool. 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: Others: /sig azure /kind bug /assign
Change:
gcp_list_resources="true" # Always pull the script from HEAD, overwriting the local one if it exists. # We do this to pick up fixes if we are running tests from a branch or tag. <del> curl -fsS --retry 3 "https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/gce/list-resources.sh" > "${gcp_list_resources_script}" </del> <ins> curl -fsS --retry 3 --keepalive-time 2 "https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/gce/list-resources.sh" > "${gcp_list_resources_script}" </ins> else gcp_list_resources="false" fi

Discussion:
http://pr- Seems like a flake? Could probably retry this, but not sure whether it's worth it.
we most definitely want to retry! Will you send a PR?
I just hit this in PR
We should close this, should be fixed by:
that didn't actually solve the problem. Per the docs, only works on "transient" errors, which the manpage defines as We might want to try passing , which some googling suggests might help. The default is 60s, which may be too long.
Please reactive this if you see it after June 15
Change:
"context" "fmt" <del> "k8s.io/klog" </del> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Logging getting points for ALL priorities set in the default scheduler policy Why is this needed: We have Kubernetes v1.14 with a problem of planning pods for three nodes. The problem is that the scheduler unevenly distributes the pods across the nodes. For example, the CPU on two nodes Node02 and Node03 are 50% loaded, while the CPU on the third Node01 is not loaded at all. While that the pods continue to be planned on Node02 and Node03, but they are not planned on Node01 at all. Scheduler logs (maximum logging level) with uniform planning: and uneven planning: As you can see, the sum of points for the priorities BalancedResourceAllocation, LeastResourceAllocation, SelectorSpreadPriority, TaintTolerationPriority is the same in both cases, but the final result is different. There is no way to understand for what specific policy priorities Node01 did not get 3 points, for to be on a par with the others, because the set of points of some priorities is not logged.
/sig scheduling
I think maybe we missed some logs which can reflect the situation of giving the score. WDYT? If you confirmed, I want to handle this issue.
Thank you for the answer! Here is the full scheduling log (logging level 10): maybe I’m really missing something, but I don’t see information about other priorities here.
Missing scores may be due to some priority functions are using non-map-reduce style, so they didn't hit the printing logic. We can add a logging function there to help you better debugging it. However, the code gets refactored in recent releases, and 1.14 is out of our supporting cycles (only 1.15, ,1.16, 1.17). Can you upgrade to a newer version, or I can provide a code snippet for you to compile on your local 1.14 branch?
Thank you, but I already solved my problem by creating an additional scheduler with a custom scheduling policies for my cronjob. However, it would be cool if you the logging function in the supported versions :)
SG. I created to address this.
I'm running v1.23.8, and I've tried and I'm still not seeing any of the scoring output you in Am I doing something wrong?

Shouldn't this be available in v1.23?
is it possible there is only 1 node candidate after filtering? In that case, the scoring logic will be bypassed as it's meaningless to score for 1 node. If it's not the case, could you check the beginning of the scheduler log, to ensure is configured properly?
Change:
"IngressRule.HTTP.Paths.Backend.Service v1": { input: netv1, output: `Name:             bar <ins> Labels:           <none> </ins> Namespace:        foo Address: Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
scheme.AddKnownTypes(SchemeGroupVersion, &PodDisruptionBudget{}, &PodDisruptionBudgetList{}, <ins> &v1.ListOptions{}, &v1.DeleteOptions{}, </ins> ) // Add the watch version that applies versionedwatch.AddToGroupVersion(scheme, SchemeGroupVersion)

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
} } <ins> func TestMetrics(t *testing.T) { mux := http.NewServeMux() InstallHandler(mux) InstallLivezHandler(mux) InstallReadyzHandler(mux) metrics.Register() metrics.Reset() paths := []string{"/healthz", "/livez", "/readyz"} for _, path := range paths { req, err := http.NewRequest("GET", fmt.Sprintf("http://example.com%s", path), nil) if err != nil { t.Errorf("%v", err) } mux.ServeHTTP(httptest.NewRecorder(), req) } expected := strings.NewReader(` # HELP apiserver_request_total [ALPHA] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, client, and HTTP response contentType and code. # TYPE apiserver_request_total counter apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version=""} 1 apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/livez",verb="GET",version=""} 1 apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/readyz",verb="GET",version=""} 1 `) if err := testutil.GatherAndCompare(legacyregistry.DefaultGatherer, expected, "apiserver_request_total"); err != nil { t.Error(err) } } </ins> func createGetRequestWithUrl(rawUrlString string) *http.Request { url, _ := url.Parse(rawUrlString) return &http.Request{

Discussion:
What would you like to be : Currently the apiserver has request latencies metrics, which are a histogram of requests to the apiserver. However, these request metrics do not include healthz. While we have recently the ability to get back health check metrics from the healthz endpoint directly, we should also emit this data as a metric, so that we can monitor health check latencies. /assign /sig api-machinery instrumentation
GitHub didn't allow me to assign the following users: jktomer. Note that only , 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 : What would you like to be : /sig api-machinery instrumentation 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 noticed this is informally assigned. Has there been any progress? Is this a place I can fit in?
Yes, I'm working on a PR.
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
return nil, false, nil } <ins> // Cannot run cloud ipam controller if cloud provider is nil (--cloud-provider not set or set to 'external') if cloud == nil && ccmConfig.ComponentConfig.KubeCloudShared.CIDRAllocatorType == string(ipam.CloudAllocatorType) { return nil, false, errors.New("--cidr-allocator-type is set to 'CloudAllocator' but cloud provider is not configured") } </ins> // failure: bad cidrs in config clusterCIDRs, dualStack, err := processCIDRs(ccmConfig.ComponentConfig.KubeCloudShared.ClusterCIDR) if err != nil {

Discussion:
Cloud-providers started to move out of tree its controller, but they share some functionalities, one of them is the NodeIPAM controller. There is a type that is GCE specific, the type. If this type is used, but no configuration for GCE is passed, the kcm panics. This can be observed in the following job: The question is, should this type be removed or a noop in KCM?
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign /cc
/sig cloud-provider
Is this a case of CCM handling IPAM so KCM needs to not handle it? What I mean is why is this set without a config? What was the intention? The fact that this has GCE-cloud-provider baked in is awful and should probably have been inverted (GCE provider calls a "register" method or something), but that's aside
Context: I started to set up jobs using the CCM by default, the cluster set up uses the script. The script doesn't consider IPAM, so it configures both KCM and CCM, but if set to "external" , it doesn't configure GCEPROVIDER in KCM When , the scripts set ... and CloudAllocator only runs with GCE My concern is that if this happens to me, it is possible that users that have to migrate custom cluster will face the same issue
A panic here seems appropriate, right? They specifically asked for a config that doesn't work and action needed to be taken. Am I misunderstanding?
A panic is appropriate given we never did any handling of this corner case -- I think it would be reasonable going forward to have a check in place to disable nodeipam controller if the allocator is but the cloud provider is not configured.
Opened with the check and a warning when this happens. We can also consider erroring out KCM if we see this happen so it's really clear to users that they misconfigured something