jiebi/CodeConvo huggingface dataset:
Code change:
if nodeConditionsChanged(newNode, oldNode) { events = append(events, queue.NodeConditionChange) } <ins> if nodeAnnotationsChanged(newNode, oldNode) { events = append(events, queue.NodeAnnotationChange) } </ins> return events } func nodeAllocatableChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </ins> } func nodeLabelsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </ins> } func nodeTaintsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </del> <ins> return !equality.Semantic.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </ins> } func nodeConditionsChanged(newNode *v1.Node, oldNode *v1.Node) bool {

Related discussion:
text: see Can we predict whether the pod is schedulable before running into scheduling cycle via the node annotations, then we can leverage the preEnqueue extension point since you already have a external controller.
Thanks for the advice. But I'm afraid it would not be the best solution for us, because doing that outside the scheduling cycle would cause the custom plugins to malfunction in my scenario.
The concerns raised by make sense to me. In my understanding, most in-tree plugins will classify the event as an event.
No. When no fit Pod, UnschedulablePlugins will have plugin(s) rejected the Pod. (e.g., all nodes don't have enough capacity, UnschedulablePlugins has noderesourcefit. all nodes don't satisfy node affinity, UnschedulablePlugins has nodeaffinity) is a rare case like plugins other than PreFilter/Filter returns non-success. I don't think we should care about it.
But, this is a good point, I think we should refactor all plugins that register event with to have a specific Node update event. For example, . It should have with instead of . event with , that should be the last-resort when we don't know which kind of Node update will make Pods schedulable. (I guess no such case at least in the in-tree plugins.)
1) One possibility is Reserve Plugin, I the capability here 2) Another possibility is PreFilter, but not because failed by the plugin, but no fit node exists Have no idea whether we have other places, I guess no. But yes, this only impacts unschedulable pods has no failed plugins.
~I think this is for intended, like ~ ~1. 1) we have a plugin failed by nodeAffinity~ ~2. 2) we add a new node~ ~3. 3) we receive the node add event, but because node not ready, we failed by nodeTaint plugin as ~ 4) node become ready, we get the node update event, but dismatch with nodeAffinity registered event (if we registered with UpdateNodeLabel event)~ ~5. 5) pod will not be moved to the active or backoff queue~ updated below
weigh in for advices as whether this is a good idea to take nodeAnnotations as a new event.
Code change:
if nodeConditionsChanged(newNode, oldNode) { events = append(events, queue.NodeConditionChange) } <ins> if nodeAnnotationsChanged(newNode, oldNode) { events = append(events, queue.NodeAnnotationChange) } </ins> return events } func nodeAllocatableChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </ins> } func nodeLabelsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </ins> } func nodeTaintsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </del> <ins> return !equality.Semantic.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </ins> } func nodeConditionsChanged(newNode *v1.Node, oldNode *v1.Node) bool {

Related discussion:
text: As I know, some plugins will read the embedded prometheus metrics in node annotations for scoring, but not for filtering. At least we should mitigate the impacts.
iv. node become ready, we get the node update event, but dismatch with nodeAffinity registered event (if we registered with UpdateNodeLabel event) (3) is not exact. When we receive the node add event, the scheduler retry to schedule the Pod because the nodeaffinity has Node add event. And it's rejected by the nodetaint plugin. (not node affinity) So, in (4), we get the node update event, it matches with node taint registered event, and the Pod is moved to active/backoffQ (node taint registers node update event. Yes I think we can change node taint's node update event to more specific one(s) though)
As I replied in your PR, we acknowledged that in , and yes let's have your patch. Well, that's a good point. So, when all nodes are filtered out by PreFilterResult, then no failedplugin can be returned. That's a problem. I think we should return the plugin name that returns PreFilterResult with not all Node names in this case (= the plugins that contributes to reducing the candidate Nodes via PreFilterResult). What do you think?
Sorry, the previous one is not right, a detailed one: a. we have a pod failed by nodeAffinity. pod will be placed into the unschedulablePods b. node autoscaler triggered, a new node , emitted a node add event c. called -d. node not ready right now and holds a notReady taint, then failed, pod still stays in the unschedulablePods e. node gets ready, emitted a node update event, but dismatch with the registered event(if we register with in nodeAffinity plugin) f. pod will stay in unschedulabelPods I guess this is the right flow. Anyway, glad to see it be more effect in the future.
If we have no performance problems, I think it's ok to take nodeAnnotations into consideration.
Wouldn't this be solved with proposal on ClusterEventWithHint? If so, I prefer we leave the existing code as-is.
whatever we do here, we wouldn't backport, so I think is the right move forward.
We put many stuff here.
Code change:
if nodeConditionsChanged(newNode, oldNode) { events = append(events, queue.NodeConditionChange) } <ins> if nodeAnnotationsChanged(newNode, oldNode) { events = append(events, queue.NodeAnnotationChange) } </ins> return events } func nodeAllocatableChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) </ins> } func nodeLabelsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </del> <ins> return !equality.Semantic.DeepEqual(oldNode.GetLabels(), newNode.GetLabels()) </ins> } func nodeTaintsChanged(newNode *v1.Node, oldNode *v1.Node) bool { <del> return !reflect.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </del> <ins> return !equality.Semantic.DeepEqual(newNode.Spec.Taints, oldNode.Spec.Taints) </ins> } func nodeConditionsChanged(newNode *v1.Node, oldNode *v1.Node) bool {

Related discussion:
text: Let me summarize each: Born from from is right. But, that's the problem with preCheck. (Some preCheck depends on some in-tree plugins' logic and it affects badly to other plugins enqueueing ) The preCheck is removed after is completed. After preCheck is removed, will be the correct behavior. So, we can do the optimization that changes node to a specific event. will be fixed in: It's kind of rare case, but I feel we need to have some improvement like Edit: create another issue for this: I'd say (2) and (3) are kind of rare cases. So, the blocker here is (1). (And, (1) is blocked by the removal of preCheck, which is blocked by ) As my conclusion, it's safer to add after (1) is done so that we can make sure the performance won't be affected badly. what do you think?
Instead, can we just keep an event for "node updated", then individual plugins can decide whether a annotations change is worth requeuing or not?
Yes, (1) can be replaced with that idea. But, I'd say changing to a specific is slightly better because the scheduling queue could filter out some Node update events without executing the hint functions.
If rescheduling can be triggered with precise events, that would be great. I haven't revisit since last time, I'll take a look again.
Since we are missing an event for , can we add it? But we also have to modify existing events like so: Because change of such field is also an Update. And in future releases we can get rid of some fine-grained events.
Since we will add hintFuncs for all in-tree plugins, so I think it's ok to add nodeAnnotationsChanged event now, we can filter out unrelated events in hitFuncs. Any other concerns? cc Prefer to keep them as people can register fine-gained events instead a general event.
If by "now" you mean v1.30, then I'm ok with that.
Code change:
import ( "fmt" <del> "os" "path/filepath" </del> "regexp" "strconv" "strings"

Related discussion:
text: <!-- 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?: What happened: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.
Code change:
import ( "fmt" <del> "os" "path/filepath" </del> "regexp" "strconv" "strings"

Related discussion:
text: Could you also verify whether fixed your problem?
tested against your commits cherry-picked on top of 1.8 beta, the fix seems to work
thanks.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: 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
Code change:
AllocatedResourcesStatus: []v1.ResourceStatus{expectedStatus}, }, } <ins> // Sort the resources for the expected status and actual status sortContainerStatuses(status.ContainerStatuses) sortContainerStatuses(expectedContainerStatuses) </ins> if !reflect.DeepEqual(status.ContainerStatuses, expectedContainerStatuses) { t.Errorf("UpdateAllocatedResourcesStatus failed, expected: %v, got: %v", expectedContainerStatuses, status.ContainerStatuses) } } <ins> // Helper function to sort ResourceHealth slices func sortResourceHealth(resources []v1.ResourceHealth) { sort.SliceStable(resources, func(i, j int) bool { return resources[i].ResourceID < resources[j].ResourceID }) } // Helper function to sort ContainerStatus slices func sortContainerStatuses(statuses []v1.ContainerStatus) { for i := range statuses { for j := range statuses[i].AllocatedResourcesStatus { sortResourceHealth(statuses[i].AllocatedResourcesStatus[j].Resources) } } } </ins>

Related discussion:
text: TestUpdateAllocatedResourcesStatus Few days ago No response No response /sig node
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
I could reproduce this with in maybe 1/10 times.
cc I am unfamilar with this code so wanted to see if you have any ideas on this.
yes, I'll have a look ASAP
In the flake, the ResourceHealth array is with a different order. If this is acceptable, we should tune the test.
nice catch ! I think the best fix is ensure the ordering of statuses either in the production code or in the test code before to check Note: if we do this in the production code then we should go full throttle and offer a full API guarantee (docs, explicit tests) because users will depend on this
A quick fix is like if we want to ignore the order.
Code change:
go_test( name = "go_default_test", srcs = [ <ins> "azure_loadbalancer_test.go", </ins> "azure_test.go", "azure_util_test.go", ],

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area cloudprovider /sig azure What happened: I've created a service of type in a Kubernetes cluster created via the ACS Engine. The load balancer has been created correctly after some time and a random NodePort (at this time ) has been allocated. However, in the Azure Portal I'm seeing that the health probe of that load balancer is pointing to port which does not exist in the whole Kubernetes system at all. Because of that wrongly configured health probe the load balancer is not reachable (i/o timeout). What you expected to happen: The health probe would have been configured to NodePort . How to reproduce it (as minimally and precisely as possible): Unfortunately, it does not behave always like this but only occasionally. In some cases the health probe gets configured correctly, but in others not. I've used the following manifest: Anything else we need to know?: When updating the health probe manually to the correct NodePort in the Azure portal, the load balancer starts to work properly. Environment: Kubernetes version (use ): 1.7.5 Cloud provider or hardware configuration: Azure Install tools: ACS Engine Others: -
Thanks for reporting the problem. Could you share the service spec after it is created? e.g. by running . And may I ask whether there is a service just removed with same name before this one?
Sure, thanks, please find the manifest below [1]. In fact I'll have some other services with the same name, but in other namespaces. In the namespace I didn't have a service named before. [1] Service manifest after creation
Filed PR , which should fix the problem. Need cherry-picked to v1.7 branch after it is merged.
Thank you very much that was really fast!
has been merged. created cherry pick PR for release 1.7.
Code change:
return "", "", err } <del> scsiController = getSCSIController(vmDevices, vs.cfg.Disk.SCSIControllerType) </del> <ins> // Get VM device list _, vmDevices, _, err := getVirtualMachineDevices(ctx, vs.cfg, vs.client, vSphereInstance) if err != nil { glog.Errorf("cannot get vmDevices for VM err=%s", err) return "", "", fmt.Errorf("cannot get vmDevices for VM err=%s", err) } scsiControllersOfRequiredType := getSCSIControllersOfType(vmDevices, diskControllerType) scsiController := getAvailableSCSIController(scsiControllersOfRequiredType) </ins> if scsiController == nil { glog.Errorf("cannot find SCSI controller in VM") // attempt clean up of scsi controller

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): v1.4.x v1.5.x v1.6.x master Environment: vSphere based install with vSphere Cloud Provider enabled. Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): NA Kernel (e.g. ):NA Install tools:kubernetes-anywhere Others: What happened: vSphere Cloud Provider configures additional SCSI adapters to scale the number of volumes that can be attached to a VM (1 adapter = 16 disks). The code within the cloud provider does not handle this correctly. Additional disks attach successfully to the VM but when k8s verifies the attach status it fails leading to k8s retrying the attach that never succeeds. In addition to this when the SCSI adapter is created for the first time the code does not use it to attach the disk leading to a failed attach disk request to the cloud provider. What you expected to happen: Additional disks should be to the VM upto the max number supported. How to reproduce it (as minimally and precisely as possible): Create a single node cluster and create a statefulset with 16 replicas or have a pod with more than 16 disks. Anything else we need to know:
A fix for this is coming up..
cc
Huh, I wonder if something changed between 1.3 and newer?
Code change:
return "", "", err } <del> scsiController = getSCSIController(vmDevices, vs.cfg.Disk.SCSIControllerType) </del> <ins> // Get VM device list _, vmDevices, _, err := getVirtualMachineDevices(ctx, vs.cfg, vs.client, vSphereInstance) if err != nil { glog.Errorf("cannot get vmDevices for VM err=%s", err) return "", "", fmt.Errorf("cannot get vmDevices for VM err=%s", err) } scsiControllersOfRequiredType := getSCSIControllersOfType(vmDevices, diskControllerType) scsiController := getAvailableSCSIController(scsiControllersOfRequiredType) </ins> if scsiController == nil { glog.Errorf("cannot find SCSI controller in VM") // attempt clean up of scsi controller

Related discussion:
text: We had tested up to 40-something volumes on 1.3. There was a fun discussion internally because it would always fail at SCSI ID 7 and I had to explain SCSI to some younger engineers :)
Code change:
// Build a detailed log of the denial. // Make the whole block conditional so we don't do a lot of string-building we won't use. <del> if glog.V(2) { </del> <ins> if glog.V(5) { </ins> var operation string if requestAttributes.IsResourceRequest() { b := &bytes.Buffer{}

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: the psp admission controller iterates through applicable psps for both the user and the service account. This leads to at least one RBAC DENY message for each pod. What you expected to happen: "RBAC DENY" should be a more meaningful message How to reproduce it (as minimally and precisely as possible): enable psp w/rbac
closing in favor of
Code change:
} // Check nodeTree after remove. The node should be removed from the nodeTree even if there are // still pods on it. <del> if cache.nodeTree.NumNodes != 0 || cache.nodeTree.Next() != "" { </del> <ins> if cache.nodeTree.NumNodes() != 0 || cache.nodeTree.Next() != "" { </ins> t.Errorf("unexpected cache.nodeTree after removing node: %v", node.Name) } }

Related discussion:
text: Description: , part of the is exporting a field which allows to modify its value externally. This also means that this field is not thread-safe. Solution: Expose a method that returns this value in a thread-safe way and do not export the field. /kind bug /sig scheduling
Code change:
import ( "fmt" "log" <del> "net/http" "net/http/httptest" </del> "reflect" "runtime" "sync"

Related discussion:
text: In 0.13.2, the apiserver has automatically exposed metrics about the process, like start time, memory usage, processor usage, etc. This stopped working sometime between then and when 0.14.0 was cut. They're still correctly exported from the kubelet, interestingly enough. An e2e or integration test is also needed to catch this if it happens again.