jiebi/CodeConvo huggingface dataset:
Change:
"runtime" "k8s.io/api/core/v1" <del> utilfeature "k8s.io/apiserver/pkg/util/feature" </del> runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2" <del> kubefeatures "k8s.io/kubernetes/pkg/features" </del> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/securitycontext"

Discussion:
Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /sig windows /milestone v1.20 /good-first-issue
This request has been marked as suitable for new contributors. 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 : Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /milestone v1.20 /good-first-issue 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
/triage accepted
Hi, how can i help with that?
Delete the codes related to these two feature gates, because they have been GA and are enabled by default
Yup, feel free to assign the issue to yourselft and then remove the features gates from the file listed above and any other places they are used in code. Thanks!
Hey, can i take this up ?
/assign
It seems that proposed it first. You can communicate with him before you start.
ok sure
/assign
Hi, Sorry by delay, but i cant push the issue branch and receive: fatal: unable to access '': The requested URL returned error: 403 I already fill the form to contriburter. Any sugestion? Regards
Before you start, you can read
i already assing to CLA and make a new branch issue-. But when i push the branch my permission is denny. any tips? Tkz
Try forking the kubernetes/kubernetes repository and then creating the pull request from a branch in your personal github repository.
Tkz, I create a PR, but i received: cla/linuxfoundation — commit missing GitHub user but i already do it. Whats is wrong?
Ok, i found the error. My name in git was wrong. Sorry, Im waiting the result for PR. Tkz
Now, i waiting for
Hi everyone, Is normal waiting this itens, or I must provide then? Tkz
Ok, Em ter., 20 de out.

de 2020 às 15:47, Mark Rossetti < : Doutor em Ciência da Computação na UNICAMP
When your code is ready, you can pull a pr from your own repo to kubernetes' repo~~ Remember to read the connection I posted earlier and the sub-connections inside.
Hi , we already past the code freeze for v1.20 and the release is due next week. At this point in time, we are considering only changes which are release blocking. Hence, I am removing this from the v1.20 milestone. Please feel to ping us on if you feel otherwise. /milestone clear
Hey Is there anything that can be done here?
Hi ! can I take this? anything required?
Hi, yes of course. Nothing to relate. Em ter., 19 de jan. de 2021 às 13:24, coderfornow <: Doutor em Ciência da Computação na UNICAMP
/assign
Change:
return false, false, false, err } <ins> // Return directly if there is any intentional predicate failure reason, so that daemonset controller skips // checking other predicate failures, such as InsufficientResourceError and unintentional errors. if hasIntentionalPredicatesReasons(reasons) { return false, false, false, nil } </ins> for _, r := range reasons { glog.V(4).Infof("DaemonSet Predicates failed on node %s for ds '%s/%s' for reason: %v", node.Name, ds.ObjectMeta.Namespace, ds.ObjectMeta.Name, r.GetReason()) switch reason := r.(type) {

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.): DaemonSet FailedPlacement Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): OL7.3 Kernel (e.g. ): 4.1.12-94.2.1.el7uek.x86_64 Install tools: Others: What happened: I have a DaemonSet that is only deployed to a subset of nodes in the cluster based on a . I'm seeing events fired with reason for the daemonset pods on nodes that do not fit the selector. What you expected to happen: These events should never fire because they do not meet the node selectors in the pod spec. How to reproduce it (as minimally and precisely as possible): Create a cluster with different sized nodes. E.g. smaller masters than workers. Then deploy the daemonset only to the workers. You will see events triggered for the master nodes that don't meet the requirements. Anything else we need to know:
DaemonSet controller will run predicates to check if node should run daemon pod. In the progress of predicates, it will check if pod fits resources first before other predicates such as PodSelectorMatches. /cc
I think this bug appeared when critical pods were introduced and order of checking predicates changed. The event is useless for daemonsets in current situation :/ I'm not sure if there is a clean way to fix it.
I feel like a clean solution would be to look at the predicate reasons twice. The first time you look at the reasons and keep track if any are not intentional. If all of the reasons are intentional then skip checking the reasons.
actually just changing the order of checks in GeneralPredicates may just work. I'm testing the fix now.
Ok, GeneralPredicates returns all reasons. Error that pod doesn't match the node is also returned but because it's "intentional" there is no event for it.

The event "Node didn't have enough resource" should be sent only when there are no other "intentional" reasons.
Yes, I think maybe we need to check reason list twice: check is in tail of predicate list.
/cc
any PR for this? If not, I can help
I will have some time to work on it next week. If you have a spare time you can create a PR.
/assign
Change:
"firewall.go", "fixture.go", "framework.go", <ins> "hostport.go", </ins> "ingress.go", "ingress_scale.go", "ingressclass.go",

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: We want to change ownership of a test from scheduler to network Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Once merges, we will exclude hostPort test on Windows. This is because of how the hostPort test is structured where we are relying on hostNetwork pod to test the communication between hostPort pods. This will not work on Windows as hostNetwork is not supported. I think it is better to have this test in sig-network and test the communication as scheduler should be responsible only for assigning a pod to node. This also ensures that hostPort on Windows is exercised properly. Anything else we need to know: More context
/sig scheduling /sig network cc
/area conformance /area test /sig windows since windows
/triage accepted
Change:
dc := l.config.Framework.DynamicClient vsc := sDriver.GetSnapshotClass(l.config) <del> dataSource, cleanupFunc := prepareSnapshotDataSourceForProvisioning(l.config.ClientNodeSelection, l.cs, dc, l.pvc, l.sc, vsc) </del> <ins> testConfig := convertTestConfig(l.config) expectedContent := fmt.Sprintf("Hello from namespace %s", f.Namespace.Name) dataSource, cleanupFunc := prepareSnapshotDataSourceForProvisioning(f, testConfig, l.cs, dc, l.pvc, l.sc, vsc, pattern.VolMode, expectedContent) </ins> defer cleanupFunc() l.pvc.Spec.DataSource = dataSource l.testCase.PvCheck = func(claim *v1.PersistentVolumeClaim) { ginkgo.By("checking whether the created volume has the pre-populated data") <del> command := fmt.Sprintf("grep '%s' /mnt/test/initialData", claim.Namespace) RunInPodWithVolume(l.cs, claim.Namespace, claim.Name, "pvc-snapshot-tester", command, l.config.ClientNodeSelection) </del> <ins> tests := []volume.Test{ { Volume:          *createVolumeSource(claim.Name, false /* readOnly */), Mode:            pattern.VolMode, File:            "index.html", ExpectedContent: expectedContent, }, } volume.TestVolumeClient(f, testConfig, nil, "", tests) </ins> } l.testCase.TestDynamicProvisioning() })

Discussion:
What happened: https://k8s- These tests failed consistently: Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /assign /sig storage
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: https://k8s- Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /sig stroage 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
hostpath driver fix:
E2e test fix: (needs hostpath driver release first).
Change:
INSTANCE_PREFIX: $(yaml-quote ${INSTANCE_PREFIX}) NODE_INSTANCE_PREFIX: $(yaml-quote ${NODE_INSTANCE_PREFIX}) NODE_TAGS: $(yaml-quote ${NODE_TAGS:-}) <ins> NODE_NETWORK: $(yaml-quote ${NODE_NETWORK:-}) NODE_SUBNETWORK: $(yaml-quote ${NODE_SUBNETWORK:-}) </ins> CLUSTER_IP_RANGE: $(yaml-quote ${CLUSTER_IP_RANGE:-10.244.0.0/16}) SERVER_BINARY_TAR_URL: $(yaml-quote ${server_binary_tar_url}) SERVER_BINARY_TAR_HASH: $(yaml-quote ${SERVER_BINARY_TAR_HASH})

Discussion:
The "Services should be able to create an internal type load balancer [Slow]" e2e test is failing on our 2k-node gce clusters - https://k8s- with the following error: We're using custom subnets for our large cluster tests, and seems like the glbc controller is not able to handle them. cc
Seems similar to Assigning to you as you seem to have the context already :) Also, is this expected to be fixed in 1.8 timeframe?
doesn't set the necessary variables for the GCE cloud provider. Will throw you a PR.
Cool - thanks a lot!
Ref
I see the last test on 09/09 failed, but I can't see the build log due to exceeding memory. Any other way I can see the log, /reopen
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
nevermind - went directly to raw log.
Friendly ping. This e2e is still failing (https://k8s-) and it's part of release-blocking suite.
/close
Change:
found:     testCase.pspFound, }, } <ins> mgr.sourcesReady = &sourcesReadyStub{} </ins> success, failure := mgr.reconcileState() if testCase.expectSucceededContainerName != "" {

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: PR , it will remove "inactive containers" while reconciling. But the cpumanager started very beginning, it will get empty activePods at it first run. This make state file no sense. What you expected to happen: We should wait a moment or notification from podmanager before starting reconcile. Some log may be before remove "inactive containers". How to reproduce it (as minimally and precisely as possible): restart kubelet 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:
/sig node
In reconcileState : You mean the cpu assignments would be wiped for the first reconciliation ?
Yes, you can test it by restarting kubelet.
Do you see any of the following log:
I see this
/assign
Change:
// of the pipe. r, w, err := r.os.Pipe() if err != nil { <del> return err </del> <ins> return newRktExitError(err) </ins> } go io.Copy(w, stdin)

Discussion:
With rkt as the container runtime, the e2e test fails with I dove into it a bit further and it looks like a real issue. With additional logging it appears that the probe does fail (exec happens and returns incorrectly as expected), but when calls it never gets that the given ID exists. The pod definition I've been using is: It restarts very slowly with rkt (on the order of an hour I believe, see sleep 600), but restarts very frequently with docker. cc
Change:
// equalLoadBalancingRulePropertiesFormat checks whether the provided LoadBalancingRulePropertiesFormat are equal. // Note: only fields used in reconcileLoadBalancer are considered. <del> func equalLoadBalancingRulePropertiesFormat(s, t *network.LoadBalancingRulePropertiesFormat) bool { </del> <ins> func equalLoadBalancingRulePropertiesFormat(s *network.LoadBalancingRulePropertiesFormat, t *network.LoadBalancingRulePropertiesFormat, wantLB bool) bool { </ins> if s == nil || t == nil { return false } <del> return reflect.DeepEqual(s.Protocol, t.Protocol) && </del> <ins> properties := reflect.DeepEqual(s.Protocol, t.Protocol) && </ins> reflect.DeepEqual(s.FrontendIPConfiguration, t.FrontendIPConfiguration) && reflect.DeepEqual(s.BackendAddressPool, t.BackendAddressPool) && reflect.DeepEqual(s.LoadDistribution, t.LoadDistribution) && reflect.DeepEqual(s.FrontendPort, t.FrontendPort) && reflect.DeepEqual(s.BackendPort, t.BackendPort) && <del> reflect.DeepEqual(s.EnableFloatingIP, t.EnableFloatingIP) && reflect.DeepEqual(s.IdleTimeoutInMinutes, t.IdleTimeoutInMinutes) </del> <ins> reflect.DeepEqual(s.EnableFloatingIP, t.EnableFloatingIP) if wantLB { return properties && reflect.DeepEqual(s.IdleTimeoutInMinutes, t.IdleTimeoutInMinutes) } return properties </ins> } // This compares rule's Name, Protocol, SourcePortRange, DestinationPortRange, SourceAddressPrefix, Access, and Direction.

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: When the Idle Timeout annotation was set to "3" which isn't a supported case, kube-controller-manager is stuck in deleting Azure LB. New service with the same name couldn't be created again even without the annotation. What you expected to happen: New service should be created successfully. 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 Since I'm seeing this on some of our clusters
/priority important-soon
Thanks
- The problem here seems that when we want to call (when processing a delete event) it reconciles the loadbalancer which in turn tries to get the idleTimeout, resulting in an error. one of the strategies is to still construct our diff in case of a delete and exercise the code path at the end. This basically translate into ignoring the error when getting idleTimeout and excluding it from finding if the rule is dirty or not when we are . toughts ? Generally speaking, whenever we update a loadbalancer with unsupported values on annotations, ensuring load balancer will fail resulting in an un-cleaned LB, this is a cross-provider issue. /sig cloud-provider cc
cc
lgtm. the delete operation should continue to do cleanup job even some wrong options are provided from users.
Change:
// used to create a 1MiB file in the target directory. initCmd := fmt.Sprintf("i=0; while [ $i -lt %d ]; do echo -n %s >>%s; let i+=1; done", loopCnt, writeBlk, ddInput) <del> clientPod := makePodSpec(config, dir, initCmd, volsrc, podSecContext) </del> <ins> clientPod := makePodSpec(config, initCmd, volsrc, podSecContext) </ins> By(fmt.Sprintf("starting %s", clientPod.Name)) podsNamespacer := cs.CoreV1().Pods(config.Namespace)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent
Change:
// TODO(liggitt): drop this once golang json parser limits stack depth (https://github.com/golang/go/issues/31789) if len(p.patchBytes) > 1024*1024 { v := map[string]interface{}{} <del> if err := json.Unmarshal(p.patchBytes, v); err != nil { </del> <ins> if err := json.Unmarshal(p.patchBytes, &v); err != nil { </ins> return nil, errors.NewBadRequest(fmt.Sprintf("error decoding patch: %v", err)) } }

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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code 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 api-machinery
/assign
Change:
// Waiting for all controller sync. internalInformers.Start(controllerCh) internalInformers.WaitForCacheSync(controllerCh) <ins> informers.Start(controllerCh) informers.WaitForCacheSync(controllerCh) </ins> // ------------------------------------------- // Test TaintNodeByCondition feature.

Discussion:
While lookint into , I spent few minutes looking into this test: And there is a problem that is relatively easy to reproduce. The problem is that we are running its test cases one by one. But nothing in the meantime is ensuring that the current state that the test assumes is reflected in scheduler. In particular the problem that I observed couple time is that: we finished one test case we call cleanupNodes [but we don't ensure that scheduler actually cleaned up this node] we start the next test case we try to schedule a pod that has some toleration (but shouldn't fit on our node) by accident the toleration make it fit on to the previous node so scheduler schedules it on the node from previous test case
/assign
Change:
cacher.ready.wait() // Ensure there is some budget for slowing down processing. <del> // When using the official `timeBudgetImpl` we were observing flakiness // due under the following conditions: </del> <ins> // We use the fakeTimeBudget to prevent this test from flaking under // the following conditions: </ins> // 1) the watch w1 is blocked, so we were consuming the whole budget once //    its buffer was filled in (10 items) // 2) the budget is refreshed once per second, so it basically wasn't

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 --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Reason for failure: Anything else we need to know: /assign
/sig api-machinery /triage accepted
OK - I can quite reliably reproduce this problem by adding before this line: This seems to be a test issue (watch being closed as a result of not being able to process stuff on time). I will think how fix the test and make it not suffer from heavy cpu starvation.
Opened fix in
Change:
// TODO: move thic logic into cni bridge plugin and remove this from kubenet func (plugin *kubenetNetworkPlugin) ensureMasqRule() error { <del> if _, err := plugin.iptables.EnsureRule(utiliptables.Append, utiliptables.TableNAT, utiliptables.ChainPostrouting, "-m", "comment", "--comment", "kubenet: SNAT for outbound traffic from cluster", "-m", "addrtype", "!", "--dst-type", "LOCAL", "!", "-d", plugin.nonMasqueradeCIDR, "-j", "MASQUERADE"); err != nil { return fmt.Errorf("Failed to ensure that %s chain %s jumps to MASQUERADE: %v", utiliptables.TableNAT, utiliptables.ChainPostrouting, err) </del> <ins> if plugin.nonMasqueradeCIDR != "0.0.0.0/0" { if _, err := plugin.iptables.EnsureRule(utiliptables.Append, utiliptables.TableNAT, utiliptables.ChainPostrouting, "-m", "comment", "--comment", "kubenet: SNAT for outbound traffic from cluster", "-m", "addrtype", "!", "--dst-type", "LOCAL", "!", "-d", plugin.nonMasqueradeCIDR, "-j", "MASQUERADE"); err != nil { return fmt.Errorf("Failed to ensure that %s chain %s jumps to MASQUERADE: %v", utiliptables.TableNAT, utiliptables.ChainPostrouting, err) } </ins> } return nil }

Discussion:
When the ip-masq-agent is activated, kubelet installs a rule that looks like: which is nonsensical.