jiebi/CodeConvo huggingface dataset:
Change:
err = proxier.iptables.RestoreAll(proxier.iptablesData.Bytes(), utiliptables.NoFlushTables, utiliptables.RestoreCounters) if err != nil { klog.Errorf("Failed to execute iptables-restore: %vnRules:n%s", err, proxier.iptablesData.Bytes()) <ins> metrics.IptablesRestoreFailuresTotal.Inc() </ins> // Revert new local ports. utilproxy.RevertPorts(replacementPortsMap, proxier.portsMap) return

Discussion:
What would you like to be : kube-proxy should expose better metrics around tracking success and failures. Administrators should be able to alert on failure counts. Why is this needed: There are several motivating cases: iptables lock contention causes to fail at an increasing rate as services + endpoints grows or are failing to execute Ultimately, there is essentially no feedback from kube-proxy if it fails to program the service network. This makes it annoyingly difficult to debug when things go wrong. As many reasonable hints we can provide should be . /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
is anyone working one this..
what cases do you think are poorly covered? /assign
thanks for triaging this :-) The specific cases are when fails - that function logs an error but doesn't otherwise surface any information. We should have a top-level metric for failing, along with any other lower-level metrics that might make sense for administrators, e.g. fails, fails.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/help-wanted
/assign
Change:
"io/ioutil" "os" "regexp" <ins> "strings" </ins> "time" "github.com/Azure/azure-sdk-for-go/services/containerregistry/mgmt/2019-05-01/containerregistry"

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-azure 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
/area provider/azure /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
{ID: "AThirdDeviceId", Health: pluginapi.Healthy}, } <del> p, e := esetup(t, devs, socket, "mock", func(n string, a, u, r []pluginapi.Device) { require.Len(t, a, 1) require.Len(t, u, 1) require.Len(t, r, 1) require.Equal(t, a[0].ID, updated[1].ID) require.Equal(t, u[0].ID, updated[0].ID) require.Equal(t, u[0].Health, updated[0].Health) </del> <ins> callbackCount := 0 callbackChan := make(chan int) callback := func(n string, a, u, r []pluginapi.Device) { // Should be called twice: // one for plugin registration, one for plugin update. if callbackCount > 2 { t.FailNow() } // Check plugin registration if callbackCount == 0 { require.Len(t, a, 2) require.Len(t, u, 0) require.Len(t, r, 0) } // Check plugin update if callbackCount == 1 { require.Len(t, a, 1) require.Len(t, u, 1) require.Len(t, r, 1) require.Equal(t, a[0].ID, updated[1].ID) require.Equal(t, u[0].ID, updated[0].ID) require.Equal(t, u[0].Health, updated[0].Health) require.Equal(t, r[0].ID, devs[1].ID) } callbackCount++ callbackChan <- callbackCount } </ins> <del> require.Equal(t, r[0].ID, devs[1].ID) }) </del> <ins> p, e := esetup(t, devs, socket, "mock", callback) </ins> defer ecleanup(t, p, e) go e.run() <ins> // Wait for the first callback to be issued. <-callbackChan </ins> p.Update(updated) <del> time.Sleep(time.Second) </del> <ins> // Wait for the second callback to be issued. <-callbackChan </ins> e.mutex.Lock() defer e.mutex.Unlock()

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 now, UT in doesn't work because callback function will never be called, is rewritten in this function : Another thing, i'm wondering why we rewrite device health in function which in this file: What you expected to happen: UT assertion should be executed. How to reproduce it (as minimally and precisely as possible): Add some logs in callback function of , it will show nothing. Anything else we need to know?: I will send a PR to fix this. /cc WDYT? /sig node
/assign
GitHub didn't allow me to assign the following users: RenaudWasTaken. Note that only 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
Good catch
Change:
--project "${PROJECT}"  --zone "${ZONE}"  --machine-type "${MINION_SIZE}"  <ins> --boot-disk-type "${MINION_DISK_TYPE}"  --boot-disk-size "${MINION_DISK_SIZE}"  </ins> --image-project="${IMAGE_PROJECT}"  --image "${IMAGE}"  --tags "${MINION_TAG}" 

Discussion:
The node disk type should be an option in the cluster/gce/config-*.sh files. The nodes get created here:
And also the disk size.
How to do this for aws ? I am stuck at 10GB minion
It . A pull request adding it would be very welcome!
please check this thread
Hello there, can I do something to make this available in the command ? I'd like to us an SSD drive :)
Change:
func Register() { // Register the metrics. registerMetrics.Do(func() { <del> for _, metric := range metricsList { legacyregistry.MustRegister(metric) } </del> <ins> RegisterMetrics(metricsList...) </ins> volumeschedulingmetrics.RegisterVolumeSchedulingMetrics() PodScheduleSuccesses = scheduleAttempts.With(metrics.Labels{"result": "scheduled"}) PodScheduleFailures = scheduleAttempts.With(metrics.Labels{"result": "unschedulable"})

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Support adding extra metrics for framework plugins Why is this needed: /sig scheduling
/assign
Change:
kube::test::get_object_assert daemonsets "{{range.items}}{{$id_field}}:{{end}}" '' # Command # Create a DaemonSet (revision 1) <del> kubectl apply -f hack/testdata/rollingupdate-daemonset.yaml "${kube_flags[@]}" </del> <ins> kubectl apply -f hack/testdata/rollingupdate-daemonset.yaml --record "${kube_flags[@]}" kube::test::get_object_assert controllerrevisions "{{range.items}}{{$annotations_field}}:{{end}}" ".*rollingupdate-daemonset.yaml --record.*" </ins> # Rollback to revision 1 - should be no-op kubectl rollout undo daemonset --to-revision=1 "${kube_flags[@]}" kube::test::get_object_assert daemonset "{{range.items}}{{$daemonset_image_field0}}:{{end}}" "${IMAGE_DAEMONSET_R1}:" kube::test::get_object_assert daemonset "{{range.items}}{{$container_len}}{{end}}" "1" # Update the DaemonSet (revision 2) <del> kubectl apply -f hack/testdata/rollingupdate-daemonset-rv2.yaml "${kube_flags[@]}" </del> <ins> kubectl apply -f hack/testdata/rollingupdate-daemonset-rv2.yaml --record "${kube_flags[@]}" </ins> kube::test::wait_object_assert daemonset "{{range.items}}{{$daemonset_image_field0}}:{{end}}" "${IMAGE_DAEMONSET_R2}:" kube::test::wait_object_assert daemonset "{{range.items}}{{$daemonset_image_field1}}:{{end}}" "${IMAGE_DAEMONSET_R2_2}:" kube::test::get_object_assert daemonset "{{range.items}}{{$container_len}}{{end}}" "2" <ins> kube::test::wait_object_assert controllerrevisions "{{range.items}}{{$annotations_field}}:{{end}}" ".*rollingupdate-daemonset-rv2.yaml --record.*" </ins> # Rollback to revision 1 with dry-run - should be no-op kubectl rollout undo daemonset --dry-run=true "${kube_flags[@]}" kube::test::get_object_assert daemonset "{{range.items}}{{$daemonset_image_field0}}:{{end}}" "${IMAGE_DAEMONSET_R2}:"

Discussion:
What happened: What you expected to happen: DS history revision 2 should have change cause from the second command "kubectl apply -f ds-2.yaml --record", not the first /assign
Change:
if _, err := fmt.Fprint(w, AppendAllLabels(options.ShowLabels, ingress.Labels)); err != nil { return err } <del> // Lay out all the rules on separate lines if use wide output. // TODO(AdoHe): improve ingress output extraLinePrefix := "" if options.WithNamespace { extraLinePrefix = "t" } for _, rules := range hostRules { if rules.HTTP == nil { continue } _, err := fmt.Fprintf(w, "%st%vt", extraLinePrefix, rules.Host) if err != nil { return err } if _, err := fmt.Fprint(w, AppendLabelTabs(options.ColumnLabels)); err != nil { return err } for _, rule := range rules.HTTP.Paths { _, err := fmt.Fprintf(w, "%st%vt%v", extraLinePrefix, rule.Path, backendStringer(&rule.Backend)) if err != nil { return err } if _, err := fmt.Fprint(w, AppendLabelTabs(options.ColumnLabels)); err != nil { return err } } } </del> return nil }

Discussion:
We should show a nicely formatted map, with tls and ports. This 50% works. Today we have: Which works well enough, but printing a single Ingress involves hand managing tabs and newlines till the entire Ingress is printed, i.e: So when we start mixing different Ingress types, we get jarring output: This is because the columns are formatted per the top ingress and don't match the bottom one. The tabbed writer used by kubectl to align columns gets confused on the whole.
you can assign this to me, will fix this next-candidate.
thanks!
Sounds like we should keep it to a single line () and move everything else to describe. Makes this bug easier.
yeah, we will move this to a single line, this is the principle.
was this finished for 1.3?
the code is already finished on my local branch. I will open a PR as I confirmed it.
what do you think if print ingress like this: Also the original resource is:
That would fall right off the screen. I think we have to stick to just printing the ips in , and everything else in . You can print hoststs alone, and optimize for small ingresses by doing something like we do for endpoints (show a small number of characters then do "..."). The problem with trying to print everything on one line is you can't represent the fanout cleanly, ie you might do: But with multiple hosts: Doesn't work, because /bar and secret2 only applies to
I agree with this, maybe we should just remove these rules from get ingress output or just leave host here.
SGTM are you going to send a pr?
yes, ready to.
Change:
// If ignoreExistErr is set to true, then the -exist option of ipset will be specified, ipset ignores the error // otherwise raised when the same set (setname and create parameters are identical) already exists. func (runner *runner) createSet(set *IPSet, ignoreExistErr bool) error { <del> args := []string{"create", set.Name, string(set.SetType), "comment"} </del> <ins> args := []string{"create", set.Name, string(set.SetType)} </ins> if set.SetType == HashIPPortIP || set.SetType == HashIPPort { args = append(args, "family", set.HashFamily,

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig network /area kube-proxy /area ipvs /assign I'll send a fixing pull request tomorrow. What happened: On centos 7.2 with ipset 6.29, kube-proxy in ipvs mode failed to create ipset sets. After some dig, it turns out to be problem of ipset on centos/rh. See I tried ipset 6.29 on ubuntu, it's OK. But when I tried ipset 6.29 on centos, I got errors: What you expected to happen: Since the problematic ipset versions have very large installation base, we could remove ipset commet, or remove ipset commet with problematic ipset version. The problematic ipset also says it support comment by --help. The problem could be detected by a test run of "ipset create foo hash:ip comment". How to reproduce it (as minimally and precisely as possible): Create some service in kubernetes, run kube-proxy with ipvs mode on Centos 7.x node. Anything else we need to know?: Environment: Kubernetes version (use ): commit (actually all commits after ) Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Linux release 7.2.1511 (Core) Kernel (e.g. ): Linux VM34centos 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others: ipset v6.29, protocol version: 6
could you test it before commit , that's ok?
, yes, I did. It's OK. But I think the we don't need to revert the iptables comments.
if ipset package not installed, will set module or match-set option in rule be weird and now seems not.
Change:
tp.disableAttach = true tp.registerDriver = true } <ins> tp.hooks = createExpansionHook(test.simulatedCSIDriverError) </ins> m.init(ctx, tp) ginkgo.DeferCleanup(m.cleanup)

Discussion:
When a pod is quickly deleted and re-created on a node, it may not be necessary to unstage the volume and in which case only node-publish is called for the volume. When this happens - stagepath won't be set for RPC call because volume was not staged even though, volume does have capability. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. Quickly delete and recreate a pod No response master Any No response_ <details</details<details</details<details</details
/sig storage /triage accepted
Change:
myConfig.BearerToken = string(test.secretTokenData) roClient := clientset.NewForConfigOrDie(&myConfig) dateBefore := time.Now().UTC().Format(dateFormat) <del> go func() { doServiceAccountAPIRequests(t, roClient, myns, true, true, false) }() doServiceAccountAPIRequests(t, roClient, myns, true, true, false) </del> <ins> var wg sync.WaitGroup concurrency := 5 for i := 0; i < concurrency; i++ { wg.Add(1) go func() { doServiceAccountAPIRequests(t, roClient, myns, true, true, false) wg.Done() }() } wg.Wait() </ins> dateAfter := time.Now().UTC().Format(dateFormat) liveSecret, err := c.CoreV1().Secrets(myns).Get(context.TODO(), test.secretName, metav1.GetOptions{}) if err != nil { t.Fatalf("Could not get secret: %v", err) } <del> if test.expectWarning && len(wh.warnings) != 8 { t.Fatalf("Expect 8 warnings, got %d", len(wh.warnings)) </del> <ins> // doServiceAccountAPIRequests has 4 API requests if test.expectWarning && len(wh.warnings) != 4*concurrency { t.Fatalf("Expect %d warnings, got %d", 4*concurrency, len(wh.warnings)) </ins> } if !test.expectWarning && len(wh.warnings) != 0 { t.Fatalf("Don't expect warnings, got %d", len(wh.warnings))

Discussion:
pull-kubernetes-integration TestLegacyServiceAccountTokenTracking (in top 10 list of flakes - ) 10/25 No response It looks like the number of warnings received is not consistent: No response /sig auth /assign /milestone v1.26 /priority important-soon we should resolve this flake before test freeze
/triage accepted
Change:
matchingAntiAffinityTerms: matchingTerms, } for predicateName, precomputeFunc := range predicatePrecomputations { <del> glog.V(4).Info("Precompute: %v", predicateName) </del> <ins> glog.V(10).Info("Precompute: %v", predicateName) </ins> precomputeFunc(predicateMetadata) } return predicateMetadata

Discussion:
Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.
Change:
cacheddiscovery "k8s.io/client-go/discovery/cached" "k8s.io/client-go/dynamic" clientset "k8s.io/client-go/kubernetes" <ins> restclient "k8s.io/client-go/rest" </ins> csiclientset "k8s.io/csi-api/pkg/client/clientset/versioned" "k8s.io/kubernetes/pkg/controller" cloudcontroller "k8s.io/kubernetes/pkg/controller/cloud"

Discussion:
In we observed a crashlooping controller cause a cluster cold boot failure, as controller-manager wasn't able to stay up long enough to run the deployment that would have fixed the problem. We should audit everything that runs in kube-controller-manager and ensure that they all fail gracefully enough to prevent crashloops, or make them individually restart in that case, instead of the process. Longer term, we should consider classifying the controllers by run level or bootstrap order (), and splitting them into separate binaries or changing the start-up order in kcm to make sure this sort of thing doesn't happen in the future.
Same issue with metrics-server, using minikube. Also reproduced on our test cluster. Steps to reproduce: Set up localkube Install metrics-server Stop minikube: sudo minikube stop Start minikube: sudo -E minikube start --vm-driver=none Expected: Kubernetes is running Actual: Kubernetes is dead Logs: Workaround: To fix the system, we must delete the metrics-server: Now kubernetes will start normally. After that we can reinstall the metrics server, and it will be ok.
Related:
This will be a hard problem to fix permanently. In all likelihood, we should stop allowing Fatalf() in kubernetes/kubernetes, but as you can see we do this to ourselves right here...
/kind bug
I also think this bug would benefit from an e2e test where we misconfigure things in a variety of ways and verify that KCM still comes up and stays up: [ ] misconfigured apiservice [ ] broken service attached to that apiservice [ ] RBAC rules that disallow things. maybe everything! [ ] webhooks that disallow everything [ ] yr example here
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:
errExpected:        context.Canceled, }, { <ins> name:               "context cancelled and immediate after 5 attempts", context:            defaultContext, callback:           defaultCallback, immediate:          true, cancelContextAfter: 5, attemptsExpected:   5, errExpected:        context.Canceled, }, { name:             "context at deadline and immediate 1 attempt expected", context:          deadlinedContext, callback:         defaultCallback, immediate:        true, attemptsExpected: 1, errExpected:      context.DeadlineExceeded, }, { </ins> name:             "context at deadline no attempts expected", context:          deadlinedContext, callback:         defaultCallback,

Discussion:
Calling wait.PollUntilContextTimeout with immediate=true does not invoke the passed condition function if context has already been cancelled. wait.PollUntilContextTimeout with immediate=true should invoke the passed condition function at least once even if context has already been cancelled as wait.PollUntilContextCancel documentation says: Note that wait.PollUntilContextTimeout wraps wait.PollUntilContextCancel, so the above should be applied to wait.PollUntilContextTimeout as well. This program panics because context ctx.Err is checked before invoking the passed function. The deprecated wait.PollImmediateWithContext does not have this kind of issue. If wait.PollUntilContextTimeout is the replacement of wait.PollImmediateWithContext, it should exhibit the same behavior. k8s v1.27.2 <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
TestloopConditionUntilContextsemantic also has an issue that immediate and sliding are not tested as expected. immediate and sliding are loop variable, but they are not used in the test. The ones that are used are in testcase struct which are always false.
/assign
ok, it seems this would do it
/assign
/triage accepted
Change:
// ApplyFeatureGates applies algorithm by feature gates. func ApplyFeatureGates() { if utilfeature.DefaultFeatureGate.Enabled(features.TaintNodesByCondition) { <del> // Remove "CheckNodeCondition" predicate </del> <ins> // Remove "CheckNodeCondition", "CheckNodeMemoryPressure" and "CheckNodeDiskPressure" predicates </ins> factory.RemoveFitPredicate(predicates.CheckNodeConditionPred) <del> // Remove Key "CheckNodeCondition" From All Algorithm Provider </del> <ins> factory.RemoveFitPredicate(predicates.CheckNodeMemoryPressurePred) factory.RemoveFitPredicate(predicates.CheckNodeDiskPressurePred) // Remove key "CheckNodeCondition", "CheckNodeMemoryPressure" and "CheckNodeDiskPressure" // from ALL algorithm provider </ins> // The key will be removed from all providers which in algorithmProviderMap[] // if you just want remove specific provider, call func RemovePredicateKeyFromAlgoProvider() factory.RemovePredicateKeyFromAlgorithmProviderMap(predicates.CheckNodeConditionPred) <ins> factory.RemovePredicateKeyFromAlgorithmProviderMap(predicates.CheckNodeMemoryPressurePred) factory.RemovePredicateKeyFromAlgorithmProviderMap(predicates.CheckNodeDiskPressurePred) </ins> // Fit is determined based on whether a pod can tolerate all of the node's taints factory.RegisterMandatoryFitPredicate(predicates.PodToleratesNodeTaintsPred, predicates.PodToleratesNodeTaints)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug Description: If TaintNodesByCondition enabled, we should disable and predicates in scheduler. In TaintNodeByCondition, we will handle those conditions: , , and ; NetworkUnavailable checking is removed by predicates, but and not (no predicate for ). /cc
/sig scheduling /sig node
/assign