jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestSyncStaticCreateNodeWithHostIP(t *testing.T) { fakeNodeHandler := &FakeNodeHandler{ CreateHook: func(fake *FakeNodeHandler, node *api.Node) bool { return true }, } nodeController := NewNodeController(nil, ".*", []string{"10.0.0.1"}, &api.NodeResources{}, fakeNodeHandler) if err := nodeController.SyncStatic(time.Millisecond); err != nil { t.Errorf("unexpected error: %v", err) } if fakeNodeHandler.CreatedNodes[0].Name != "10.0.0.1" { t.Errorf("unexpect node %v created", fakeNodeHandler.CreatedNodes[0].Name) } if fakeNodeHandler.CreatedNodes[0].Status.HostIP != "10.0.0.1" { t.Errorf("unexpect nil node HostIP for node %v", fakeNodeHandler.CreatedNodes[0].Name) } } </ins> func TestSyncStaticCreateNodeWithError(t *testing.T) { fakeNodeHandler := &FakeNodeHandler{ CreateHook: func(fake *FakeNodeHandler, node *api.Node) bool {

Discussion:
Why doesn't the 'node' entity have a hostname and/or IP fields? Currently its id field (soon to become name field) holds the IP but is that something that a REST api consumer can firmly rely on to get the node's IP/hostname so this field 'name/id' will always hold IP/hostname and not other information? (IP/hostname is useful for example for visualization of the minions available in a k8s cluster in UI and showing their IP/hostnames)
Minion does have a HostIP field in v1beta1, and NodeStatus has a HostIP field in v1beta3. When you GET the resource, is the value for that field not set? If so, on what cloudprovider? It's true that there is no hostname field, but the minion/node name itself is the hostname.
, I'm currently using the hack/local cluster setup , this is the output of GET for minion 127.0.0.1 with v1beta1, seems that HostIP is not returned at all (even not with empty value) { "kind": "Node", "id": "127.0.0.1", "uid": "-8527-11e4-8f4b-", "creationTimestamp": "2014-12-16T15:31:50+02:00", "selfLink": "/api/v1beta1/minions/127.0.0.1", "resourceVersion": 7, "apiVersion": "v1beta1", "resources": { "capacity": { "cpu": 1000, "memory": } } } Can you please elaborate/point to docs about the change in v3? so HostIP field is moved into a NodeStatus section/internal to Node entity? BTW why is it considered part of a status? thank you
The best documentation of v1beta3 is unfortunately the source right now: It adheres to the conventions described here: The fact that HostIP is not reported is probably a quirk with static minions. In reality, hosts can have multiple IP addresses, some private and some public, v4 and v6, dynamically assigned (e.g., using DHCP), etc. For now, we support single, private, static IP addresses, but in cases where hosts are specified using hostnames, the IP addresses are looked up.

So, status makes the most sense to me.
Yeah, HostIP is only queried from cloudprovider. you won't see hostIP in json if it's empty (see the tag)
why HostIP is not returned for local static setup? the id reflects the IP anyhow. it sounds like a bug, but this issue is tagged with "documentation".
Yes, I agree that it's a bug that HostIP isn't populated. The documentation aspect is to explain somewhere why it's in Status rather than Spec.
Change:
// Last scale time lastScaleTime   *metav1.Time recommendations []timestampedRecommendation <ins> finished bool </ins> } // Needs to be called under a lock.

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!--What happened: Resync period for HorizontalPodAutoscaler controller is set to 15 seconds in order to update HPAs every 15 seconds. Sometimes updates are skipped and period between two updates is 30 seconds. What you expected to happen: HPA should be updated every 15 seconds. How to reproduce it (as minimally and precisely as possible): Add debugs to HPA controller showing how often HPAs are processed. Create HPA. Anything else we need to know?: HPA controller uses rate RateLimitingQueue: New requests are always with 15 seconds delay: If request for the given HPA is in the queue then newly request is skipped. Requests are and removed from the queue at the same moment so there is a race condition. See following scenario: 00:00:00 - Resync adds request to queue to be executed at 00:00:15 00:00:15 - Resync adds next request to queue to be executed at 00:00:30 but it is skipped because previous request is still in the queue 00:00:15 - Request at 00:00:00 is executed 00:00:30 - Resync adds next request to queue to be executed at 00:00:45 00:00:45 - Request at 00:00:30 is executed In above scenario HPA wasn't updated between 00:00:15 and 00:00:45. Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: GKE <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig autoscaling
/assign krzysztof-jastrzebski
Change:
ret.OIDCCAFile = s.OIDC.CAFile ret.OIDCClientID = s.OIDC.ClientID ret.OIDCGroupsClaim = s.OIDC.GroupsClaim <ins> ret.OIDCGroupsPrefix = s.OIDC.GroupsPrefix </ins> ret.OIDCIssuerURL = s.OIDC.IssuerURL ret.OIDCUsernameClaim = s.OIDC.UsernameClaim <ins> ret.OIDCUsernamePrefix = s.OIDC.UsernamePrefix </ins> } if s.PasswordFile != nil {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: --oidc-username-prefix option for api-server seems to not have any effect. The apiserver is running with --oidc-username-prefix=-, and if I'm changing ClusterRoleBinding username from prefix#username to username, I'm still getting: What you expected to happen: When using the "--oidc-username-prefix=-", the username should be "<user_id", without issuer prefix How to reproduce it (as minimally and precisely as possible): Follow the steps to set up the OIDC authentication, add "--oidc-username-prefix=-" to apiserver config file, restart kubelet, create client config for OIDC, try "kubeadm get nodes" Anything else we need to know?: I'm wondering if users are cached somewhere? Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-20T19:11:02Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-20T05:17:43Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: kubeadm OS (e.g. from /etc/os-release): centos 7.4
/sig auth
/assign
Re-opening for cherry pick.
The same issue is occurring with the flag.
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 2 days, the issue will be moved out of the v1.8 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.

: Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Fix has been cherry picked. Fix will be available in v1.8.5 /close
Change:
Context("when scheduling a read only busybox container", func() { podName := "busybox-readonly-fs" + string(uuid.NewUUID()) <del> It("should not write to root filesystem [NodeConformance]", func() { </del> <ins> /* Release : v1.13 Testname: Kubelet, pod with read only root file system Description: Create a Pod with security context set with ReadOnlyRootFileSystem set to true. The Pod then tries to write to the /file on the root, write operation to the root filesystem MUST fail as expected. */ framework.ConformanceIt("should not write to root filesystem [NodeConformance]", func() { </ins> isReadOnly := true podClient.CreateSync(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{

Discussion:
What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. To my eyes they may meet the criteria for conformance. There's definitely nothing about them that is node specific. They should be running as part of our regular CI, and they should probably be running as presubmits. Porting them to test/e2e/common would cause this to happen. /kind cleanup /sig node /area test /assign
GitHub didn't allow me to assign the following users: mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. /sig node /area test /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
Change:
"k8s.io/kubernetes/pkg/volume/util/fsquota/common" ) <ins> // Pod -> External Pod UID var podUidMap = make(map[types.UID]types.UID) </ins> // Pod -> ID var podQuotaMap = make(map[types.UID]common.QuotaID)

Discussion:
I have kubernetes 1.24.7. I tried to use on formated volume. It works until first reboot. After reboot, I get messages: I expect that project quota can be assigned even after reboot. Use xfs for /var/lib/containerd with discard,quota,prjquota No response <details</details<detailsbaremetal </details<details</details<details</details<detailsrke2 </details<details</details
/sig node Can this be reproduced? Can this pod be recreated correctly if you force delete the pod?
/triage accepted
It can be reproduced. Pod is created if I remove . I can test force delete.
/assign we are looking into gate to understand if we need to keep it or deprecate it.
If I force delete pod, it does not start again:
/assign Let me check on the latest code with the fix
Change:
return nil } <ins> // initializeVolume creates a filesystem on given volume, so it can be used as read-only later func initializeVolume(cs clientset.Interface, ns string, pvc *v1.PersistentVolumeClaim, node e2epod.NodeSelection) { if pvc.Spec.VolumeMode != nil && *pvc.Spec.VolumeMode == v1.PersistentVolumeBlock { // Block volumes do not need to be initialized. return } ginkgo.By(fmt.Sprintf("Initializing a filesystem on PVC %s", pvc.Name)) // Just create a pod with the volume as read-write. Kubernetes will create a filesystem there // if it does not exist yet. podConfig := e2epod.Config{ NS:            ns, PVCs:          []*v1.PersistentVolumeClaim{pvc}, SeLinuxLabel:  e2epv.SELinuxLabel, NodeSelection: node, } pod, err := e2epod.CreateSecPod(cs, &podConfig, framework.PodStartTimeout) defer func() { framework.ExpectNoError(e2epod.DeletePodWithWait(cs, pod)) }() framework.ExpectNoError(err) } </ins>

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
framework.ExpectNoError(err) ginkgo.By("Deleting a ReplicationController") <del> err = f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Delete(replicationController.Name, nil) </del> <ins> // Without the delete options, the object isn't actually // removed until the GC verifies that all children have been // detached. ReplicationControllers default to "orphan", which // is different from most resources. (Why? To preserve a common // workflow from prior to the GC's introduction.) err = f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Delete(replicationController.Name, &metav1.DeleteOptions{ PropagationPolicy: func() *metav1.DeletionPropagation { p := metav1.DeletePropagationBackground return &p }(), }) </ins> framework.ExpectNoError(err) ginkgo.By("Ensuring resource quota status released usage")

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-e2e-gce Which test(s) are flaking: [sig-api-machinery] ResourceQuota should verify ResourceQuota with best effort scope. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a replication controller. [Conformance] [sig-api-machinery] ResourceQuota should verify ResourceQuota with terminating scopes. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a pod. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a secret. [Conformance] Testgrid link: Reason for failure: I'm guessing it's a timeout waiting for resource quota to get refreshed, eg: Anything else we need to know: links to specific failures /sig api-machinery /priority important-soon
/cc
For , observed the following in kube- around the above time period:
We hit today as well. FYI
/assign
failed with a timeout for PR . see:
FYI I figured out the problem by looking at the audit logs and seeing the "orphan" finalizer. We looked there due to observing successful PUTs to the RC's status after it was supposedly deleted.
Change:
systemCritical = scheduling.SystemCriticalPriority <del> critical = v1.Pod{ </del> <ins> clusterCritical = v1.Pod{ </ins> Spec: v1.PodSpec{ <del> Priority: &systemCritical, </del> <ins> PriorityClassName: scheduling.SystemClusterCritical, Priority:          &systemCritical, Containers: []v1.Container{ { Resources: v1.ResourceRequirements{}, }, }, }, } systemNodeCritical = scheduling.SystemCriticalPriority + 1000 nodeCritical = v1.Pod{ Spec: v1.PodSpec{ PriorityClassName: scheduling.SystemNodeCritical, Priority:          &systemNodeCritical, </ins> Containers: []v1.Container{ { Resources: v1.ResourceRequirements{},

Discussion:
<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --I'd like only pods to have low OOM score -997. introduced a change which ensured all the critical priority classes will have a low OOM score -997. While this helped in relating OOM score to priority of pod, it also allows containers in pods to have -997 OOM score, making them one of the last processes to be OOMKilled. By definition pods can be scheduled elsewhere if there is crunch on the node where as pods cannot be rescheduled. This was the reason for to have higher priority value than . So, I think it makes sense for only pods to have low OOM score of -997. /sig node cc
/triage accepted
i think this is reasonable since is higher priority than and this would make a distinction between the two making killable but assured to be rescheduled
Note that oomscore has nothing to do with rescheduling. Eviction looks at priority, oomscore simply controls the killer. I think that strengthens the argument - the point of node-critical is makinng sure it's killed last, but even then that should be a rare, rare case (a memory leak in kube-proxy will blow out the workload, but if we just killed kube-proxy everything would heal). We may want to go back to the original justifications for -99x oomscore in system-node-critical and make sure we're still aligning correctly.
Change:
sed -i -e "s@{{ *pillar['cluster_registry_disk_size'] *}}@${CLUSTER_REGISTRY_DISK_SIZE}@g" "${registry_pvc_file}" sed -i -e "s@{{ *pillar['cluster_registry_disk_name'] *}}@${CLUSTER_REGISTRY_DISK}@g" "${registry_pvc_file}" fi <del> # TODO(piosz): figure out how to not run fluentd-es pod from fluentd daemon set on master. #              Running fluentd-es on the master is pointless, as it can't communicate #              with elasticsearch from there in the default configuration. </del> if [[ "${ENABLE_NODE_LOGGING:-}" == "true" ]] &&  [[ "${LOGGING_DESTINATION:-}" == "elasticsearch" ]] &&  [[ "${ENABLE_CLUSTER_LOGGING:-}" == "true" ]]; then

Discussion:
Fluentd-elastcisearch sends logs to an Elasticsearch installation inside the cluster. It uses ES service to access, so it doesn't work on master, because there's no kube-proxy on master. Because of that, introducing master toleration to in was unnecessary.
Change:
return nil, errors.New(err) } <del> containerName = t.Spec.Containers[0].Name } else { containerName = opts.Container </del> <ins> currOpts.Container = t.Spec.Containers[0].Name </ins> } <del> container, fieldPath := podcmd.FindContainerByName(t, containerName) </del> <ins> container, fieldPath := podcmd.FindContainerByName(t, currOpts.Container) </ins> if container == nil { <del> return nil, fmt.Errorf("container %s is not valid for pod %s", opts.Container, t.Name) </del> <ins> return nil, fmt.Errorf("container %s is not valid for pod %s", currOpts.Container, t.Name) </ins> } ref, err := reference.GetPartialReference(scheme.Scheme, t, fieldPath) if err != nil {

Discussion:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close 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:
} By("wait for the rc to be deleted") // TODO: shorten the timeout when we make GC's periodic API rediscovery more efficient. <ins> // Tracked at https://github.com/kubernetes/kubernetes/issues/50046. </ins> if err := wait.Poll(5*time.Second, 90*time.Second, func() (bool, error) { _, err := rcClient.Get(rc1.Name, metav1.GetOptions{}) if err == nil {

Discussion:
Perhaps it has the same root cause as
Case 1: Delete request sent at: Cycle removed at: Deletion of pods: The cycle was removed. And the pods were deleted properly. But it took 43s in total. API rediscovery in that period: Which took 16s.
Case 2: Delete request: Cycle removed at: Pods deleted at: Took 41 seconds. API re-discovery: Took 13s. Another thing I noticed is that the re-discovery always traverses the discovery endpoints back-to-back twice.
case 3: Deletion started at: GC first action at: Watch latency is around 5s. Cycle removed at GC deletes the Pods at: Took 30s. API re-discovery: Took 10s.
The cause is the same as . The periodic API rediscovery adds latency. Also, the watch latency is also quite high. I'll send a PR to increase the timeout
: Deletion started at: GC's first action at: GC deletes the last Pod at: Took 99s. Experienced 3 API re-discoveries: 37s in total
The test is much after we extended the timeout to 90s. We can further extend the timeout if needed.
Change:
package kuberuntime import ( <del> "runtime" </del> "testing" "github.com/stretchr/testify/assert"

Discussion:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </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 windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted