jiebi/CodeConvo huggingface dataset:
Change:
eventsRule(), rbacv1helpers.NewRule("create").Groups(legacyGroup).Resources("endpoints", "secrets", "serviceaccounts").RuleOrDie(), rbacv1helpers.NewRule("delete").Groups(legacyGroup).Resources("secrets").RuleOrDie(), <del> rbacv1helpers.NewRule("get").Groups(legacyGroup).Resources("endpoints", "namespaces", "secrets", "serviceaccounts").RuleOrDie(), </del> <ins> rbacv1helpers.NewRule("get").Groups(legacyGroup).Resources("endpoints", "namespaces", "secrets", "serviceaccounts", "configmaps").RuleOrDie(), </ins> rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("endpoints", "secrets", "serviceaccounts").RuleOrDie(), // Needed to check API access.  These creates are non-mutating rbacv1helpers.NewRule("create").Groups(authenticationGroup).Resources("tokenreviews").RuleOrDie(),

Discussion:
BUG REPORT: /kind bug /sig auth What happened: Kubernetes distro testing v1.12.0-rc.2 shows in setups with self-hosted control planes (i.e. apiserver, controller-manager, scheduler run as pods) that previously worked on v1.11.3 and prior, the kube-controller-manager now crash loops with: The kube-controller-manager is run with a with a to the default system ClusterRole , which seems to be defined at Editing the ClusterRole manually to add for was sufficient to fix the crash loop. What you expected to happen: I suspect a change between v1.11.3 and v1.12.0 release candidates altered kube-controller-manager to begin looking for configmap , but didn't update the ClusterRoles. How to reproduce it (as minimally and precisely as possible): Release candidate testing is happening in Anything else we need to know?: Environment: Kubernetes version (use kubectl version): v1.12.0-rc.2 Cloud provider or hardware configuration: GCE, DigitalOcean, AWS OS (e.g. from /etc/os-release): Container Linux 1855.4.0 Kernel (e.g. uname -a): 4.14.67-coreos Install tools: Typhoon
/sig cluster-lifecycle /area kubeadm /remove-sig auth edit: sorry, got this mixed up with another 1.12/1.11 issue. is this related to the secured controller manager work you did? /remove-sig cluster-lifecycle /sig auth /sig api-machinery
Those labels are not set on the issue: <detailsIn response to : /sig cluster-lifecycle /area kubeadm /remove-sig auth /sig auth /sig api-machinery 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
can you please try if works to skip that lookup?
we can make this non-fatal, compare
adding that flag to the controller-manager does also work to skip the lookup, without me manually editing the ClusterRole. Although if controller-manager defaults to looking up the configmap, I'd imagine the clusterrole should default to allowing configmap get's, no?

i was just checking if there's a work around we could suggest for 1.12 :) longer term, we can lean towards whatever and decide (adding to bootstrap policy vs making things non-fatal)
This seems like it should get a Known Issue comment in the release notes for 1.12. Can somebody please draft test and drop it in the known issues bucket issue ASAP?
Change:
} } <ins> // resourceRequest = max(sum(podSpec.Containers), podSpec.InitContainers) + overHead </ins> func calculateResource(pod *v1.Pod) (res Resource, non0CPU int64, non0Mem int64) { resPtr := &res for _, c := range pod.Spec.Containers { resPtr.Add(c.Resources.Requests) non0CPUReq, non0MemReq := schedutil.GetNonzeroRequests(&c.Resources.Requests) non0CPU += non0CPUReq non0Mem += non0MemReq // No non-zero resources for GPUs or opaque resources. } <ins> for _, ic := range pod.Spec.InitContainers { resPtr.SetMaxResource(ic.Resources.Requests) non0CPUReq, non0MemReq := schedutil.GetNonzeroRequests(&ic.Resources.Requests) if non0CPU < non0CPUReq { non0CPU = non0CPUReq } if non0Mem < non0MemReq { non0Mem = non0MemReq } } </ins> // If Overhead is being utilized, add to the total requests for the pod if pod.Spec.Overhead != nil && utilfeature.DefaultFeatureGate.Enabled(features.PodOverhead) { resPtr.Add(pod.Spec.Overhead) if _, found := pod.Spec.Overhead[v1.ResourceCPU]; found { non0CPU += pod.Spec.Overhead.Cpu().MilliValue() }

Discussion:
The scheduler does not properly calculate pod requests for a resource as - it ignores init containers completely in . This would allow a workload to get "free" scheduling above the limit of containers (mitigated by quota, which calculates this properly) and so the scheduler would make non-optimal fits. Both kubelet and scheduler enforce the , so you can't actually schedule, but you sometimes get steered to the wrong node if you have more init container resource usage than containers. in should use and the similar helpers instead of writing its own method to calculate the request for resources. /sig scheduling
/priority important-soon
Let me follow this issue. /assign
fyi
After I checked the implementation of function, I think we just need to use it to instead of the function in the scheduler.
/priority critical-urgent
Is the pod phase not considered? When the pod phase is running, the requested resource is actually considered as . This change seems to reduce the resource utilization of the node.
Actually, I don't think we need to consider the pod.Phase. The resource request & limit are mainly used in the scheduling process. The scenario you said is not belong to the responsibility of kube-scheduler
Correct. Setting appropriate requests/limits that maintain good node usage is users responsibility. Considering the max(initContainers, sum(containers)) is the documented behavior.
I understand. Thank you for your comments!
Change:
func failedPodsBackoffKey(ds *apps.DaemonSet, nodeName string) string { return fmt.Sprintf("%s/%d/%s", ds.UID, ds.Status.ObservedGeneration, nodeName) } <ins> // getPodsWithoutNode returns list of pods assigned to not existing nodes. func getPodsWithoutNode( runningNodesList []*v1.Node, nodeToDaemonPods map[string][]*v1.Pod) []string { var results []string isNodeRunning := make(map[string]bool) for _, node := range runningNodesList { isNodeRunning[node.Name] = true } for n, pods := range nodeToDaemonPods { if !isNodeRunning[n] { for _, pod := range pods { results = append(results, pod.Name) } } } return results } </ins>

Discussion:
What happened: DaemonSet doesn't delete pods that: weren't scheduled yet, node was deleted so pod can't be scheduled. What you expected to happen: Pod should be deleted when node is removed. How to reproduce it (as minimally and precisely as possible): I encountered this problem when doing tests with cluster with 1000 nodes and pods running. During tests I was deleting and adding nodes using GCE API without draining them. I reproduced problem on much smaller cluster but it requires stopping K8s scheduler. Scenario: cluster with 2 nodes. till fluentd-gcp pods are running on nodes. K8s scheduler. fluentd-gcp pods. till daemonset controller creates pending pods. one node. scheduler. of the fluentd-gcp pods will be pending and scheduler won't be able to schedule. Anything else we need to know?: Environment: GKE Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig apps
/assign janetkuo
/assign
We have PodGC to clean up orphaned pods every 20s, is that enough?
I'm removing pods that have only node affinity set and don't have pod.Spec.NodeName set. These pods were never touched by scheduler before node was removed and after node was removed can't be scheduled as node is doesn't exist anymore. Such pods are pending forever and PodGC can't remove them as pod.Spec.NodeName is empty.
Yes, that's right :) let me take few time to review the PR, thanks.
Should I backport fix to 1.13 and 1.12?
+1
Change:
"verb", verb, "URI", rl.req.RequestURI, "latency", latency, <del> "userAgent", rl.req.UserAgent(), </del> <ins> // We can't get UserAgent from rl.req.UserAgent() here as it accesses headers map, // which can be modified in another goroutine when apiserver request times out. // For example authentication filter modifies request's headers, // This can cause apiserver to crash with unrecoverable fatal error. // More info about concurrent read and write for maps: https://golang.org/doc/go1.6#runtime "userAgent", rl.userAgent, </ins> "audit-ID", auditID, "srcIP", rl.req.RemoteAddr, } <ins> // Lock for accessing addedKeyValuePairs and addedInfo rl.mutex.Lock() defer rl.mutex.Unlock() </ins> keysAndValues = append(keysAndValues, rl.addedKeyValuePairs...) if rl.hijacked {

Discussion:
Apiserver crashed with stacktrace: Not to crash I was able to reproduce it by "slowing down" deleting headers in Authentication filter (): And making requests (around 5-10 requests to trigger this race condition): Crash was caused by race condition - one goroutine was modifying headers of requests (for example authentication filter). The other goroutine was trying to get UserAgent from request, which is also taken from request's headers map. This causes unrecoverable panic. <detailsAll versions, tested on 1.21 </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /priority important-soon
/triage accepted
Reopening - since we need to cherrypick it to previous releasses.
- friendly ping on opening cherrypicks
I've opened two cherry-picks:
One more for 1.20:
All merged - thanks!
Change:
} simpleMsg, detailedMsg := volumeToMount.GenerateMsg("MountVolume.NodeExpandVolume succeeded", "") og.recorder.Eventf(volumeToMount.Pod, v1.EventTypeNormal, kevents.FileSystemResizeSuccess, simpleMsg) <ins> og.recorder.Eventf(pvc, v1.EventTypeNormal, kevents.FileSystemResizeSuccess, simpleMsg) </ins> klog.Infof(detailedMsg) // File system resize succeeded, now update the PVC's Capacity to match the PV's err = util.MarkFSResizeFinished(pvc, pvSpecCap, og.kubeClient)

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: Kubelet does send the pvc resize success events when expanding pvc (node expand) What you expected to happen: Kubelet sends the pvc resize success events when expanding pvc (node expand) successfully How to reproduce it (as minimally and precisely as possible): Plugin supports node expand the external-reszier(csi reszier) pvc pod pvc expanded, but did not see the events Anything else we need to know?: Environment: 1.16.1 Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage
/assign
more details. pvc pod If we do not send the successful expansion event, it is hard to know the result. I think we should also send the event to pvc
note that events are not guaranteed to be delivered (the event recorder throttles event reporting over certain thresholds)
Thanks, after I read the codes, I find the event did not send
Change:
"--master", fmt.Sprintf("--cluster-version=%s", v), "--quiet") <del> return err </del> <ins> if err != nil { return err } waitForSSHTunnels() return nil </ins> } func NodeUpgrade(f *Framework, v string, img string) error {

Discussion:
Upgrade fails with: Error from: https://k8s- Related failures: https://k8s- https://k8s-
/cc
might require how do the GKE tests interact with the defaults you set up?
Looks like are pretty isolated to upgrade tests.
Also we didn't start seeing this until the ABAC default change merged so I think change might help
it will definitely help with the GCE jobs mentioned in the description of
I haven't looked at the logs, so sorry if this is just noise, but the symptom (couldn't get logs b/c pod doesn't exist) looks very similar to what happened when the kubectl taint e2e tests were running in parallel instead of serial.
Judging by the comment and digging into the history , this used to be wrapped in a retry loop. It was removed in PR
it looks like this is limited to gke jobs in the upgrade tests. since getting pod logs depends on master-node communications, it would be affected by the SSH tunnels issue ()
Not blocking under guidance
Change:
return c.DiscoveryObj } <ins> func (c *FakeClientSet) GetPossibleResources() []*metav1.APIResourceList { return c.DiscoveryObj.PossibleResources } </ins> // Create a fake Clientset with its Discovery method overridden. func NewFakeClientset(fakeDiscovery FakeDiscoveryWithError) *FakeClientSet { cs := &FakeClientSet{}

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:
// newControllerManagerCommand creates a *cobra.Command object with default parameters func newHollowNodeCommand() *cobra.Command { s := &hollowNodeConfig{ <del> NodeLabels: make(map[string]string), </del> <ins> NodeLabels:        make(map[string]string), ExtendedResources: make(map[string]string), </ins> } cmd := &cobra.Command{

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
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
/sig scalability
Change:
// ServiceBackendPort is the service port being referenced. type ServiceBackendPort struct { // Name is the name of the port on the Service. <ins> // This must be an IANA_SVC_NAME (following RFC6335). </ins> // This is a mutually exclusive setting with "Number". // +optional Name string

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: Tried to create an ingress with a backend serviceport pointing to a service with a port name with length 15 chars that is valid from the service point of view. But failed because the validation for Ingress does not match the one for service. Service Validation (uses DNS Label): ) Ingress Service Port Validation (uses IANA format like for container ports): What you expected to happen: Service port validation should match Ingress ServicePort validation How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-11-16T17:18:52Z", GoVersion:"go1.15.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.10", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-10-15T01:43:56Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network
It's not friendly to users who create service with long service port name, to create ingress with port reference. Although, the port name of service is editable. Maybe, we can add warning message for service creation and update when the port name is not a valid ingress port name.
I'm fine with a doc change mentioning the restriction similar to the restriction in the doc for container port () where it explicitly says about the IANASVCNAME constraint
/triage accepted /assign
Change:
snapshot = NewEmptySnapshot() for _, op := range test.operations { <del> op() </del> <ins> op(t) </ins> } if len(test.expected) != len(cache.nodes) {

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
KUBELET_FLAGS=${KUBELET_FLAGS:-""} # Name of the network plugin, eg: "kubenet" NET_PLUGIN=${NET_PLUGIN:-""} <del> # Place the binaries required by NET_PLUGIN in this directory, eg: "/home/kubernetes/bin". NET_PLUGIN_DIR=${NET_PLUGIN_DIR:-""} </del> <ins> # Place the config files and binaries required by NET_PLUGIN in these directory, # eg: "/etc/cni/net.d" for config files, and "/opt/cni/bin" for binaries. CNI_CONF_DIR=${CNI_CONF_DIR:-""} CNI_BIN_DIR=${CNI_BIN_DIR:-""} </ins> SERVICE_CLUSTER_IP_RANGE=${SERVICE_CLUSTER_IP_RANGE:-10.0.0.0/24} FIRST_SERVICE_CLUSTER_IP=${FIRST_SERVICE_CLUSTER_IP:-10.0.0.1} # if enabled, must set CGROUP_ROOT

Discussion:
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 ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.
Change:
func NewStubContainerManagerWithExtendedResource(shouldResetExtendedResourceCapacity bool) ContainerManager { return &containerManagerStub{shouldResetExtendedResourceCapacity: shouldResetExtendedResourceCapacity} } <ins> func NewStubContainerManagerWithDevicePluginResource(extendedPluginResources v1.ResourceList) ContainerManager { return &containerManagerStub{ shouldResetExtendedResourceCapacity: false, extendedPluginResources:             extendedPluginResources, } } </ins>

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
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
/sig scalability
Change:
return nil, err } <ins> initIface := iface if initiatorName != "" { iface = bkportal[0] + ":" + spec.Name() } </ins> return &iscsiDisk{ podUID:        podUID, VolName:       spec.Name(), Portals:       bkportal, Iqn:           iqn, Lun:           lun, <ins> InitIface:     initIface, </ins> Iface:         iface, chapDiscovery: chapDiscovery, chapSession:   chapSession,

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