jiebi/CodeConvo huggingface dataset:
Change:
"//pkg/scheduler/testing:go_default_library", "//pkg/scheduler/util:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.

If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.
Change:
w.Write([]byte(output)) } <ins> redirectHandler := func(s int, bad bool) func(w http.ResponseWriter, r *http.Request) { return func(w http.ResponseWriter, r *http.Request) { if r.URL.Path == "/" { http.Redirect(w, r, "/new", s) } else if bad && r.URL.Path == "/new" { w.WriteHeader(http.StatusInternalServerError) } } } </ins> prober := New() testCases := []struct { handler    func(w http.ResponseWriter, r *http.Request)

Discussion:
It seems the http liveness probe will not follow a 302 redirect and instead reports a failure. I found this in some testing on 1.0.6 and have not yet verified the same behavior on latest. Do you agree that it should check the redirected path on a 302? If so, where would be the best place to check the response code and handle this?
Why would you set your health-check URL to a redirect? , Dan Wilson wrote:
In this case it was a versioned health check where /v1/health or /v2/health is the correct check and /health directs to the correct one.
hmm, I could buy following redirects, I guess. It's a little weird if it redirects off-host, but who am I to say it is wrong? , Dan Wilson wrote:
Following redirects for a health check seems weird to me as well... I definitely wouldn't expect it to by default.
Seems like it would be cleaner to make respond the same as instead of making all health consumers follow redirects.
I agree that it's cleaner to call /health and make that route the same as /<latest/health but due to the framework used for this project it's not handled that way. Following the HTTP standards is important as well, right? curl handles this with an additional option (-L), could we do the same by adding a parameter?
I think it should follow local redirects without complaining (can well differentiate local vs non?). The real question is non-local redirects - should it a) work, b) not work, c) work iff a flag-field in the probe , Dan Wilson wrote:
old thread here... I agree with non-local redirects not being allowed, just doesn't seem to make sense. If we get a 301 perhaps we could get the value of the redirect ( it looks like there is a Location header with the new full path ) and then do something like the following: the root URL of the redirect location. it's a DNS name attempt to resolve it to an IP. If that fails, just bail. the IP to make sure it's in the cluster. If it's not in our CIDR block bail. the redirect. thoughts?

/sig node /sig network
Adding to 1.8 milestone
Is it not possible and easier to simply empower the user by adding an option for "unexceptional" status codes? They could declare 200-only (default) or all-but-errors.
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.9 milestone for more than 3 days: priority: Must specify exactly one of , or . <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
This contradicts docs , opened
Change:
EmptyDir *EmptyDir `json:"emptyDir"` // GCEPersistentDisk represents a GCE Disk resource that is attached to a // kubelet's host machine and then exposed to the pod. <del> GCEPersistentDisk *GCEPersistentDisk `json:"persistentDisk"` </del> <ins> GCEPersistentDisk *GCEPersistentDisk `json:"gcePersistentDisk"` </ins> // GitRepo represents a git repository at a particular revision. GitRepo *GitRepo `json:"gitRepo"` }

Discussion:
As long as we have it in the API, it should maybe be renamed to gcePersistentDisk ?
SGTM
Change:
} if len(b.resources) != 0 { <del> return &Result{err: fmt.Errorf("resource(s) were provided, but no name, label selector, or --all flag specified")} </del> <ins> for _, r := range b.resources { _, err := b.mappingFor(r) if err != nil { return &Result{err: err} } else { return &Result{err: fmt.Errorf("resource(s) were provided, but no name, label selector, or --all flag specified")} } } </ins> } return &Result{err: missingResourceError} }

Discussion:
Hello! I got this error: or:
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Do I need to use ?
use instead
Change:
DEBUG=${DEBUG:-"false"} <ins> # Add SSH_OPTS: Add this to config ssh port SSH_OPTS="-oPort=22 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oLogLevel=ERROR" </ins>

Discussion:
Hi, Right now in the installation script for Ubuntu there are hardcoded SSH_OPTS. In my case I am using a custom SSH port, and, unless I am mistaken, I have no way to customize it, either globally or on a per-host basis. Would it be possible to do that? I can try to submit a patch if necessary. Thanks.
Yes, please. Just send a PR to add in and make it configurable.
Change:
} for _, test := range testCases { <del> ss, err := newTestScaleSet(ctrl, test.scaleSet, test.zone, test.faultDomain, test.vmList) </del> <ins> cloud := GetTestCloud(ctrl) if test.location != "" { cloud.Location = test.location } setTestVirtualMachineCloud(cloud, test.scaleSet, test.zone, test.faultDomain, test.vmList, "Running") scaleset, err := newScaleSet(cloud) </ins> assert.NoError(t, err, test.description) <ins> ss := scaleset.(*scaleSet) </ins> real, err := ss.GetZoneByNodeName(test.nodeName) if test.expectError {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .
Change:
return true } <del> // AreLabelsInWhiteList verifies if the provided label list // is in the provided whitelist and returns true, otherwise false. func AreLabelsInWhiteList(labels, whitelist Set) bool { if len(whitelist) == 0 { return true } for k, v := range labels { value, ok := whitelist[k] if !ok { return false } if value != v { return false } } return true } </del> // ConvertSelectorToLabelsMap converts selector string to labels map // and validates keys and values func ConvertSelectorToLabelsMap(selector string) (Set, error) {

Discussion:
What happened: The function return when whitelist is empty. The function is implemented as follows: What you expected to happen: When the whitelist is empty, any key of labels can not in it. Should the function return when whitelist is empty?
/sig api-machinery
/assign /cc (we think you might have opinions on fixing this)
I only see one consumer. Rather than change the semantic, I would suggest moving it to the point of use and renaming it.
Yes, this function is wrong, I agree with David. P.S. we don't advertise interface stability for this library so this is OK. But even if we did, I think callers of this function are probably not expecting this behavior and should be examined.) P.P.S. The way it should work is via set difference, the labels should be a subset of the list. P.P.P.S. These are sets and not lists, and the names should be changed to reflect that. P.P.P.P.S. If you're making a change here anyway, please lose the word "whitelist".
Okay, I will submit a pr.
Change:
- [Metrics Changes](#metrics-changes) - [Added metrics](#added-metrics) - [Removed metrics](#removed-metrics) <del> - [Depreciated/changed metrics](#depreciatedchanged-metrics) </del> <ins> - [Deprecated/changed metrics](#deprecatedchanged-metrics) </ins> - [Notable Features](#notable-features) - [Beta](#beta) - [Alpha](#alpha)

Discussion:
What happened: There's a typo typo in and What you expected to happen: “depreciated” should be “deprecated”. How to reproduce it (as minimally and precisely as possible): View the release notes Anything else we need to know?: /lifecycle active I have a PR to fix this /sig docs Environment: Kubernetes version (use ): v1.16 Cloud provider or hardware configuration: not applicable OS (e.g: ): not applicable Kernel (e.g. ): not applicable Install tools: not applicable
Change:
} for _, pod := range pods.Items { <del> for _, c := range pod.Spec.Containers { </del> <ins> for i, c := range pod.Spec.Containers { </ins> name := pod.ObjectMeta.Name + "/" + c.Name <del> if logging[name] { </del> <ins> if logging[name] || // sanity check, array should have entry for each container len(pod.Status.ContainerStatuses) <= i || // Don't attempt to get logs for a container unless it is running or has terminated. // Trying to get a log would just end up with an error that we would have to suppress. (pod.Status.ContainerStatuses[i].State.Running == nil && pod.Status.ContainerStatuses[i].State.Terminated == nil) { </ins> continue } readCloser, err := LogsForPod(ctx, cs, ns, pod.ObjectMeta.Name,

Discussion:
When running some GCE PD CSI Driver E2E tests this warning gets printed out repeatedly. Looks like it's in a tight retry loop. 1) What needs to be fixed so that this error doesn't happen? 2) If it does error out, can it retry a couple times then give up. Right now it just continuously prints these warning statements drowning out any other log signals. /cc not sure who has the most context on this <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig storage
I wrote that code. The error message comes from this API here: And gets printed here: The code gets triggered by pod events. At least to me it wasn't clear when log retrieval is supposed to succeed and when it is expected to fail, so the operation simply gets retried until it succeeds. If this "the server does not allow this method on the requested resource" error is normal and can be ignored, then it can be to the regex in and then it'll get suppressed.
/assign
These particular logs might be from the daemonset pod that is trying to run on the master node
Michelle Au <: It looks like test logs are incomplete (). If true, then this permission issue permanently prevents capturing log output. Does anyone have an idea how to get logs in this setup?
I'm not sure about that, the logs show: as the driver running on the node. Edit: This is not ture, this could still be the master node, the daemonset names all its pods like this
I think it would be much better if we could figure out the source of the error and remedy it instead of turning off logs for server errors altogether
The log spam is making it really difficult to run the tests locally:
Saad Ali <: As you can reproduce it, do you have an explanation for why this permission error occurs? All I can do is suppress the error, but I think we all agree that this shouldn't be done without understanding the issue first.
I haven't confirmed but I think it's from the daemonset pod that is trying to unsuccessfully run on the master node. I think we could try to skip pods that are not actually running
FWIW it only happens when the test is failing.
Saad Ali <: So perhaps it really has to do something with trying to get logs for pods that couldn't start? Does help?
Change:
// update initiatorname params["iface.initiatorname"] = b.InitiatorName // create new iface <del> out, err = b.exec.Run("iscsiadm", "-m", "iface", "-I", newIface, "-o", "new") </del> <ins> out, err = b.exec.Run("iscsiadm", "-m", "iface", "-I", b.Iface, "-o", "new") </ins> if err != nil { exit, ok := err.(utilexec.ExitError) if ok && exit.ExitStatus() == iscsiadmErrorSessExists { <del> klog.Infof("iscsi: there is a session already logged in with iface %s", newIface) </del> <ins> klog.Infof("iscsi: there is a session already logged in with iface %s", b.Iface) </ins> } else { lastErr = fmt.Errorf("iscsi: failed to create new iface: %s (%v)", string(out), err) return lastErr

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign
Change:
"github.com/blang/semver" dockertypes "github.com/docker/engine-api/types" <ins> dockernat "github.com/docker/go-connections/nat" </ins> "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require"

Discussion:
This is in 1.6.0-beta.4: Some context: The line number suggests it is here: I think this is because dockershim now uses a protobuf object and Protocol is now an int. And is allowed in go (apparently) - is "A". And the comedic error is because Protocol implements If this is the error, there's something fishy going on because all our UDP tests should fail?
Aha ... I think it is only UDP hostports that would be "broken" by the issue. I wouldn't be surprised if we don't rely on any, and that we might not have any test coverage. I don't think this is a regression - I think this code has been there since the start of dockershim, but maybe CRI is now the default? I don't know how widely UDP hostports are used. Given how close we are to the planned release date, cc and
There is something wrong in dockershim's protocol parsing. Will file an PR to fix this. /assgin
/assign
Opened to fix this.
thanks for filing the issue. Thanks for quickly addressing the bug. We need node e2e tests to capture the kind of regression at the first place.
Change:
return v.configuration.Load().([]webhook.WebhookAccessor) } <del> // HasSynced returns true if the shared informers have synced. </del> <ins> // HasSynced returns true when the manager is synced with existing webhookconfig // objects at startup-- which means the informer is synced and either has no items // or updateConfiguration() has completed. </ins> func (v *validatingWebhookConfigurationManager) HasSynced() bool { <del> return v.hasSynced() </del> <ins> if !v.hasSynced() { return false } if v.initialConfigurationSynced.Load().(bool) { // the informer has synced and configuration has been updated return true } if configurations, err := v.lister.List(labels.Everything()); err == nil && len(configurations) == 0 { // the empty list we initially stored is valid to use. // Setting initialConfigurationSynced to true, so subsequent checks // would be able to take the fast path on the atomic boolean in a // cluster without any admission webhooks configured. v.initialConfigurationSynced.Store(true) // the informer has synced and we don't have any items return true } return false </ins> } func (v *validatingWebhookConfigurationManager) updateConfiguration() {

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: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: 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:
} if glog.V(10) { for _, hostPriority := range results[index] { <del> glog.Infof("%v -> %v: %v, Score: (%d)", pod.Name, hostPriority.Host, config.Name, hostPriority.Score) </del> <ins> glog.Infof("%v -> %v: %v, Score: (%d)", util.GetPodFullName(pod), hostPriority.Host, config.Name, hostPriority.Score) </ins> } } }(i, priorityConfig)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In pkg/scheduler/core/generic_scheduler# , add some debug info: each scheduler extender's score and its name for each pod, e.g. And we need add a function(e.g. ) in interface to get extender's name or similar identity. For , it might be enough to return its url . Why is this needed: If there are two or more scheduler extenders configured for scheduler(and we have now), it will be very useful to debug why kubelet nodes get so high/low score. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
Reiterating the mentions to trigger a notification: <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
Why don't you send a PR instead?
Thanks. PR is sent. PTAL.
Change:
"kuberuntime_sandbox_test.go", "labels_test.go", "legacy_test.go", <del> "security_context_test.go", </del> <ins> "security_context_others_test.go", "security_context_windows_test.go", </ins> ], embed = [":go_default_library"], deps = [

Discussion:
Hello, What happened: When we apply PodSecurityPolicy with rule: WIndows containers are still blocked instead we put: the pod is still blocked with logs: What you expected to happen: the Container should start How to reproduce it (as minimally and precisely as possible): Create Psp disableling Root Users: Create a pod Windows with runAsUserName: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.3 Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux 7 (Core) / windows server 2019 version 1809 Kernel (e.g. ): 3.10.0-514.10.2.el7.x86_64 Others: /sig windows
/sig windows
/assign I will test it and then post the test results
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
Change:
// +optional optional string volumeMode = 6; <del> // This field requires the VolumeSnapshotDataSource alpha feature gate to be // enabled and currently VolumeSnapshot is the only supported data source. // If the provisioner can support VolumeSnapshot data source, it will create // a new volume and data will be restored to the volume at the same time. // If the provisioner does not support VolumeSnapshot data source, volume will </del> <ins> // This field can be used to specify either: // * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) // * An existing PVC (PersistentVolumeClaim) // In order to use VolumeSnapshot object types, the appropriate feature gate // must be enabled (VolumeSnapshotDataSource) // If the provisioner can support the specified data source, it will create // a new volume based on the contents of the specified PVC or Snapshot. // If the provisioner does not support the specified data source, the volume will </ins> // not be created and the failure will be reported as an event. // In the future, we plan to support more data source types and the behavior // of the provisioner may change.

Discussion:
/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /sig api 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