jiebi/CodeConvo huggingface dataset:
Change:
}, }, }) <ins> pod, err := f.PodClient().Get(name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred()) // TODO: remove hardcoded kubelet volume directory path // framework.TestContext.KubeVolumeDir is currently not populated for node e2e hostLogFile = "/var/lib/kubelet/pods/" + string(pod.UID) + "/volumes/kubernetes.io~empty-dir" + logFile </ins> }) It("should generate node condition and events for corresponding errors", func() {

Discussion:
Leads to this avc: In general, HostPath volumes in tests are bad news for selinux.
Change:
cmd := &cobra.Command{ Use:     "selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]", Short:   "Set the selector on a resource", <del> Long:    fmt.Sprintf(selectorLong), </del> <ins> Long:    fmt.Sprintf(selectorLong, validation.LabelValueMaxLength), </ins> Example: selectorExample, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(options.Complete(f, cmd, args, out))

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} What happened:
Could someone from please help with triage. Thanks!
There is already a PR on the way.
Change:
{DesiredState: cpuAndMemory, CurrentState: machine2State}, }, }, <ins> { nodes:        []api.Minion{makeMinion("machine1", 0, 0), makeMinion("machine2", 0, 0)}, expectedList: []HostPriority{{"machine1", 0}, {"machine2", 0}}, test:         "zero minion resources", pods: []api.Pod{ {DesiredState: cpuOnly, CurrentState: machine1State}, {DesiredState: cpuAndMemory, CurrentState: machine2State}, }, }, </ins> } for _, test := range tests {

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Change:
if priorityConfigs[i].Function != nil { wg.Add(1) go func(index int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_legacy").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_legacy").Dec() wg.Done() }() </ins> var err error results[index], err = priorityConfigs[index].Function(pod, nodeNameToInfo, nodes) if err != nil {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign
Change:
// NewRecorder returns an EventRecorder that can be used to send events to this EventBroadcaster // with the event source set to the given event source. NewRecorder(scheme *runtime.Scheme, source v1.EventSource) EventRecorder <ins> // Shutdown shuts down the broadcaster Shutdown() </ins> } // Creates a new event broadcaster.

Discussion:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash
Change:
// Attempt 2 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-x50vb")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-jk9rt")), </ins> // Attempt 3 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-scq98")), core.NewUpdateAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, serviceAccount(addNamedTokenSecretReference(emptySecretReferences(), "default-token-scq98"))), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-684pg")), core.NewUpdateAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, serviceAccount(addNamedTokenSecretReference(emptySecretReferences(), "default-token-684pg"))), </ins> }, }, "new serviceaccount with no secrets encountering unending create error": {

Discussion:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.
Change:
if params["create-external-load-balancer"] == "true" { service.Spec.CreateExternalLoadBalancer = true } <del> if len(params["public-ip"]) == 0 { </del> <ins> if len(params["public-ip"]) != 0 { </ins> service.Spec.PublicIPs = []string{params["public-ip"]} } return &service, nil

Discussion:
expose hostnames --port=80 --container-port=9376 --selector="app=hostnames" get se hostnames -o yaml apiVersion: v1beta1 containerPort: "9376" ... obviously, endpoints controller is not happy.
Change:
<ins> load("@io_bazel_rules_go//go:def.bzl", "go_library", "go_test") go_library( name = "go_default_library", srcs = ["pod_topology_spread.go"], importpath = "k8s.io/kubernetes/pkg/scheduler/framework/plugins/podtopologyspread", visibility = ["//visibility:public"], deps = [ "//pkg/scheduler/algorithm/predicates:go_default_library", "//pkg/scheduler/framework/plugins/migration:go_default_library", "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/nodeinfo:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", ], ) go_test( name = "go_default_test", srcs = ["pod_topology_spread_test.go"], embed = [":go_default_library"], deps = [ "//pkg/scheduler/algorithm/predicates:go_default_library", "//pkg/scheduler/framework/plugins/migration:go_default_library", "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/nodeinfo:go_default_library", "//pkg/scheduler/testing:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", ], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], visibility = ["//visibility:public"], ) </ins>

Discussion:
What would you like to be : Add a filter plugin that calls into EvenPodsSpread predicate, example Why is this needed: Part of /sig scheduling /help /priority important-soon
/assign
/remove-help
/retitle: [migration phase 1] EvenPodsSpread as filter plugin
/retitle [migration phase 1] EvenPodsSpread as filter plugin
/assign /unassign
May I take over this?
is going to take this over after the offline discussion, and he is familiar with EvenPodsSpread
IC, thanks a lot.
Change:
} }, "spec": { <del> "replicas": 2, </del> <ins> "replicas": 8, </ins> "selector": { "name": "nettest" },

Discussion:
It's failing on both GCE and GKE-CI. It appears to have broken somewhere around build number 2509/2510 which includes a likely candidate PR (). /cc
I was about to debug this one. I'll take it.
Root cause is almost definitely one of these: Summary secrets example pod (details) the permissions on python files. (details) the implementation of DeepCopy to use reflection instead of Gob encode/decode. (details) networking test (details) back to executable. (details) protected docker processes (-900) (details) proxySocket out of to (details) Commit by Fix secrets example pod The file was modified Commit by Fixing the permissions on python files. The file was modified cluster/juju/charms/trusty/kubernetes- The file was modified cluster/juju/return-node- The file was modified cluster/juju/charms/trusty/kubernetes- Commit by Changing the implementation of DeepCopy to use reflection instead of Gob encode/decode. The file was The file was modified The file was modified Commit by Fix networking test The file was modified contrib/for-tests/network- The file was modified contrib/for-tests/network- The file was modified The file was modified contrib/for-tests/network-tester/Makefile Commit by Changing back to executable. The file was modified Commit by OOM protected docker processes (-900) The file was modified The file was modified The file was modified Commit by Move proxySocket out of to Moves proxySocket out of to new in proxy package in order to start separating proxy logic and implementation and make proxier more manageable to review. The file was modified The file was
Pretty sure it's commit , so rolling back now. cc .
The above rollback solved that immediate problem, but now the test, while proceeding healthily, is timing out. More debugging or optimization required: Networking should function for intra-pod communication ..... [irrelevant stuff deleted] ..... INFO: Proxy status call returned in 4.861944ms INFO: Attempt 35/60: test still running INFO: About to make a proxy status call Build timed out (after 90 minutes). Marking the build as aborted. Build timed out (after 90 minutes). Marking the build as failed. Ran 40 of 46 Specs in 5069.444 seconds FAIL!

-- 18 Passed 5 Skipped Build was aborted Recording test results
I'm not entirely sure why, but the test is running normally again, completing consistently in 13 seconds. Closing this issue for now. !
Change:
Egress []NetworkPolicyEgressRule `json:"egress,omitempty" protobuf:"bytes,3,rep,name=egress"` // List of rule types that the NetworkPolicy relates to. <del> // Valid options are Ingress, Egress, or Ingress,Egress. </del> <ins> // Valid options are "Ingress", "Egress", or "Ingress,Egress". </ins> // If this field is not specified, it will default based on the existence of Ingress or Egress rules; // policies that contain an Egress section are assumed to affect Egress, and all policies // (whether or not they contain an Ingress section) are assumed to affect Ingress.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: bug report /kind bug What happened: I was reading the documentation for as defined What you expected to happen: To have clear documentation How to reproduce it (as minimally and precisely as possible): Read the following, as seen in the 1.12 docs: Anything else we need to know?: Nope Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Is it a case whereby only can be specified as , or only , or both (note the ) ? If that's the case, do you think the following would make it clearer?
It is confusing to have commas used for English grammar and array element delineation in the same sentence. What about simply this?
sounds like a great fix! Putting out a quick pr with this change now :)
Change:
// Let the controller-manager allocate Node CIDRs for the Pod network. // Each node will get a subspace of the address CIDR provided with --pod-network-cidr. if cfg.Networking.PodSubnet != "" { <del> command = append(command, "--allocate-node-cidrs=true", "--cluster-cidr="+cfg.Networking.PodSubnet) </del> <ins> maskSize := "24" if ip, _, err := net.ParseCIDR(cfg.Networking.PodSubnet); err == nil { if ip.To4() == nil { maskSize = "64" } } command = append(command, "--allocate-node-cidrs=true", "--cluster-cidr="+cfg.Networking.PodSubnet, "--node-cidr-mask-size="+maskSize) </ins> } return command }

Discussion:
/kind bug What happened: Currently, if the user sets the cidr with --pod-network-cidr with kubeadm, the kube-controller-manager is passed the cidr with the --cluster-cidr arg. --node-cidr-mask-size is not passed to the kube-controller-manager and the controller-manager used the default value of 24 The default value of 24 if good for IPv4, but for IPv6 the controller-manager throws an error because the node-cidr-mask-size is incorrect. What you expected to happen: The user should be able to specify the node-cidr-mask-size for IPv6 How to reproduce it (as minimally and precisely as possible): Use Kubeadm specify an IPv6 address with --pod-network-cidr. with a subnet greater than 24. For example kubeadm init --pod-network-cidr=2001:101::0/64 Anything else we need to know?: Environment: IPv6 Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): 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
/area ipv6 /area kubeadm
/assign rpothier
Change:
return fmt.Errorf("invalid container mount point %v", myMountPoint) } myMPSlash := myMountPoint + string(os.PathSeparator) <del> // The previously found nested mountpoint (or "" if none found yet) prevNestedMP := "" </del> <ins> // The previously found nested mountpoints. // NOTE: We can't simply rely on sort.Strings to have all the mountpoints sorted and // grouped. For example, the following strings are sorted in this exact order: // /dir/nested, /dir/nested-vol, /dir/nested.vol, /dir/nested/double, /dir/nested2 // The issue is a bit worse for Windows paths, since the 's value is higher than /'s: // dirnested, dirnested-vol, dirnested.vol, dirnested2, dirnesteddouble // Because of this, we should use a list of previously mounted mountpoints, rather than only one. prevNestedMPs := []string{} </ins> // examine each mount point to see if it's nested beneath this volume // (but skip any that are double-nested beneath this volume) // For example, if this volume is mounted as /dir and other volumes are mounted

Discussion:
to have all the mount points sorted and grouped. For example, the following strings are sorted in this exact order: With the current implementation, test, we would get: This is worse on Windows, where paths usually have backslashes instead (with no test changes): [1] ` should group mount points correctly. /kind bug /sig windows Kubernetes master, Kubernetes v1.25 and older. N/A N/A <details</details<details</details<details</details
/triage accepted /milestone v1.26
Change:
templates := set.Spec.VolumeClaimTemplates claims := make(map[string]v1.PersistentVolumeClaim, len(templates)) for i := range templates { <del> claim := templates[i] claim.Name = getPersistentVolumeClaimName(set, &claim, ordinal) </del> <ins> claim := templates[i].DeepCopy() claim.Name = getPersistentVolumeClaimName(set, claim, ordinal) </ins> claim.Namespace = set.Namespace if claim.Labels != nil { for key, value := range set.Spec.Selector.MatchLabels {

Discussion:
The kube-controller-manage may crash when processing StatefulSet with spec.podManagementPolicy is Parallel. With logs: we expect the kube-controller-manage will work well. The following example can reproduce this problem: After digging into the source code, we found that when using the pod management policy, the statefulset controller will use to start parallel processing. But the which is called during parallel processing may directly update the claims' labels without a lock. This finally causes a concurrent map-accessing problem. <details</details<details</details<details</details<details</details<details</details<details</details
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
/sig apps
Thanks for the report. Do we know when this issue was introduced? cc
Maybe it was imported by this pr
We can reproduce this issue in unit testing.
The reported versions is and it seems that PR got backported further /priority important-soon
/assign
The original report looks like could have introduced it, yes. I wonder if we intentionally modify template without creating a copy (and as it seems, assign the exact same labels every time we use this template for any pod): Regardless, that was probably safe before the pod creations were parallelized. I don't think the proposed unit test catches the bug (more on that below), but we can probably reproduce it by timing pod state transitions so that many pods are simultaneously pending and missing a PVC. I ran this test on (before the cherry-pick of parallel statefulset scaling), and it also failed. This is because the test itself introduces a concurrent map write. It probably doesn't replicate the issue, and I don't think it can be merged, as it'll fail even if the original PR is reverted. For reproduction we'd need to catch a concurrent write without adding one in test code, just as it happened based on the original report.
Turns out we never tested this path at all, since the test PVC didn't have any labels of its own.

After adding labels, existing tests are sufficient to detect race condition. PR showing that improved test detects the issue: PR with fix and improved test:
Sweet! thanks !
Change:
// <matchSum> indicates how many pods (on current node) match the <constraint>. matchSum := int64(0) for _, existingPod := range nodeInfo.Pods() { <ins> // Bypass terminating Pod (see #87621). if existingPod.DeletionTimestamp != nil || existingPod.Namespace != pod.Namespace { continue } </ins> if c.selector.Matches(labels.Set(existingPod.Labels)) { matchSum++ }

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
t.Errorf("unexpected error: %v", err) } <ins> // We need to set custom timestamp which is not the same as the one on existing PV // - doing so will prevent timestamp update on phase change and custom one is used instead. pvStartTimestamp = &metav1.Time{Time: pvStartTimestamp.Time.Add(time.Second)} </ins> pvIn := &api.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Status: api.PersistentVolumeStatus{ <del> Phase: api.VolumeBound, // Set the same timestamp as original PV so this won't get updated on phase change breaking DeepEqual() later in test. </del> <ins> Phase:                   api.VolumeBound, </ins> LastPhaseTransitionTime: pvStartTimestamp, }, }

Discussion:
pkg/registry/core/persistentvolume/storage TestUpdateStatus unknown No response /sig storage
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
/priority important-soon as it failed in master blocking