Question: "github.com/robfig/cron/v3" batchv1 "k8s.io/api/batch/v1" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime"

Changing the label on a job template in a CronJob causes any Jobs held by the successful/failed history parameters to stop being tracked, so they never get cleaned up. Jobs with labels that don't match the (upgraded) CronJob, but still have an owner reference, should be subject to the history limit. a CronJob with a job template containing label , and non-zero history limit the CronJob to run and generate some Jobs (default 3 successful, 1 failed) the CronJob with a job template containing label the CronJob to run and generate some more Jobs there are more than 3 successful Jobs/1 failed Job! I believe this is the relevant code: The CronJob controller finds Jobs that it should care about by matching on the labels in the job template, this obviously breaks if the labels in the job template change. 21 Self-hosted No response No response No response No response_
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
Experiencing another side-effect of this bug. If job template labels are updated while a cronjob has status (a scheduled job is running), then that cronjob gets stuck in . The cause seems to be the same as describes: once the job template labels are updated, cronjob controller V2 loses track of the jobs with the old labels, and therefore never updates the status of that active cronjob to indicate that the scheduled job has completed.
/assign


Question: t.Fatal(err) } <del> // Start informer factory after initialization informerFactory.Start(ctx.Done()) // Feed testing data and wait for them to be synced </del> <ins> t.Log("Feed testing data and wait for them to be synced") </ins> client.StorageV1().StorageClasses().Create(ctx, immediateSC, metav1.CreateOptions{}) client.StorageV1().StorageClasses().Create(ctx, waitSC, metav1.CreateOptions{}) if item.node != nil {

<!-- 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: The unit test Which test(s) are flaking: Testgrid link: Reason for failure: In volume scheduling, we maintain internal caches that watch for PV/PVC events. However, we don't have a method to wait for them to be synced in UT. When the cache in the informer factory is synced but the execution of registered handlers may not finish. <!-- In production, this is not a problem. Even if the scheduler marks the pod uncacheable due to the stale cache in PVAssumeCache/PVCAssumeCache, the pod will be moved to the active queue later as the scheduler . related: --Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig scheduling /sig storage
Even if I check the PV/PVC assume cache and wait for PV/PVC objects to be into the cache, the PV/PVC objects may not be . It seems that the shared informer with the fake client has a bug that registered event handlers may not be called (or handlers are not registered successfully).
The share informer with the fake client may miss events of objects which are created before caches are synced. it's better to create testing objects before starting the informers
Although the event handlers may not finish when the caches were synced in theory, however, it seems it's not necessary to wait for PV/PVC assume cache to be synced practically. I've run a thousand times (parallel: 10) with locally and no failures.


Question: framework.Logf("Status.Condition: %#v", statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1]) }) <del> ginkgo.It("should apply an update to a Namespace", func() { </del> <ins> /* Release: v1.26 Testname: Namespace, apply update to a namespace Description: When updating the namespace it MUST succeed and the field MUST equal the new value. */ framework.ConformanceIt("should apply an update to a Namespace", func() { </ins> var err error var updatedNamespace *v1.Namespace ns := f.Namespace.Name

[X] Test approval issue: [X] Test PR: 27 Aug 2022 [x] Two weeks soak end date: 9 Sept 2022 [x] Test promotion PR: According to this APIsnoop query, there are still a remaining Namespace endpoint which is untested. replaceCoreV1Namespace Using a number of existing e2e test practices a new has been created for 1 Namespace endpoint. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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


Question: if sp.failScore { return 0, framework.NewStatus(framework.Error, fmt.Sprintf("injecting failure for pod %v", p.Name)) } score := 10 <del> if nodeName == sp.highScoreNode { </del> <ins> if sp.numCalled == 1 { // The first node is scored the highest, the rest is scored lower. sp.highScoreNode = nodeName </ins> score = 100 } return score, nil

What happened: The new TestScorePlugin for the scheduler framework is flaky How to reproduce it (as minimally and precisely as possible): An example: Anything else we need to know?: The test evaluates that a pod should be scheduled on specific node with a higher score. I think the test sometimes fails because the higher score node that the test creates didn't propagate yet to the scheduler (i.e., the node exists in etcd, but scheduler hasn't been notified that it exists yet, and so it is not evaluated at all). /kind bug /sig scheduling /assign
/kind flake


Question: func init() { api.Scheme.AddDefaultingFuncs( <ins> func(obj *ReplicationController) { if len(obj.DesiredState.ReplicaSelector) == 0 { obj.DesiredState.ReplicaSelector = obj.DesiredState.PodTemplate.Labels } if len(obj.Labels) == 0 { obj.Labels = obj.DesiredState.PodTemplate.Labels } }, </ins> func(obj *Volume) { if util.AllPtrFieldsNil(&obj.Source) { obj.Source = VolumeSource{

It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.


Question: --project "${PROJECT}" || true; } <ins> # Assumes: # - NUM_MIGS # - NODE_INSTANCE_PREFIX # - PROJECT # - ZONE # - ENABLE_NODE_AUTOSCALER # - TARGET_NODE_UTILIZATION # - AUTOSCALER_MAX_NODES # - AUTOSCALER_MIN_NODES </ins> function create-autoscaler() { # Create autoscaler for nodes if requested if [[ "${ENABLE_NODE_AUTOSCALER}" == "true" ]]; then <del> METRICS="" </del> <ins> local metrics="" </ins> # Current usage <del> METRICS+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/cpu/node_utilization," METRICS+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " METRICS+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/memory/node_utilization," METRICS+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " </del> <ins> metrics+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/cpu/node_utilization," metrics+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " metrics+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/memory/node_utilization," metrics+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " </ins> # Reservation <del> METRICS+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/cpu/node_reservation," METRICS+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " METRICS+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/memory/node_reservation," METRICS+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " </del> <ins> metrics+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/cpu/node_reservation," metrics+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " metrics+="--custom-metric-utilization metric=custom.cloudmonitoring.googleapis.com/kubernetes.io/memory/node_reservation," metrics+="utilization-target=${TARGET_NODE_UTILIZATION},utilization-target-type=GAUGE " </ins> echo "Creating node autoscalers." <del> local max_instances_per_mig=$(((${AUTOSCALER_MAX_NODES} + ${num_migs} - 1) / ${num_migs})) local last_max_instances=$((${AUTOSCALER_MAX_NODES} - (${num_migs} - 1) * ${max_instances_per_mig})) local min_instances_per_mig=$(((${AUTOSCALER_MIN_NODES} + ${num_migs} - 1) / ${num_migs})) local last_min_instances=$((${AUTOSCALER_MIN_NODES} - (${num_migs} - 1) * ${min_instances_per_mig})) </del> <ins> local max_instances_per_mig=$(((${AUTOSCALER_MAX_NODES} + ${NUM_MIGS} - 1) / ${NUM_MIGS})) local last_max_instances=$((${AUTOSCALER_MAX_NODES} - (${NUM_MIGS} - 1) * ${max_instances_per_mig})) local min_instances_per_mig=$(((${AUTOSCALER_MIN_NODES} + ${NUM_MIGS} - 1) / ${NUM_MIGS})) local last_min_instances=$((${AUTOSCALER_MIN_NODES} - (${NUM_MIGS} - 1) * ${min_instances_per_mig})) </ins> <del> for i in $(seq $((${num_migs} - 1))); do </del> <ins> for i in $(seq $((${NUM_MIGS} - 1))); do </ins> gcloud compute instance-groups managed set-autoscaling "${NODE_INSTANCE_PREFIX}-group-$i" --zone "${ZONE}" --project "${PROJECT}"  <del> --min-num-replicas "${min_instances_per_mig}" --max-num-replicas "${max_instances_per_mig}" ${METRICS} || true </del> <ins> --min-num-replicas "${min_instances_per_mig}" --max-num-replicas "${max_instances_per_mig}" ${metrics} || true </ins> done gcloud compute instance-groups managed set-autoscaling "${NODE_INSTANCE_PREFIX}-group" --zone "${ZONE}" --project "${PROJECT}"  <del> --min-num-replicas "${last_min_instances}" --max-num-replicas "${last_max_instances}" ${METRICS} || true </del> <ins> --min-num-replicas "${last_min_instances}" --max-num-replicas "${last_max_instances}" ${metrics} || true </ins> fi }

cc:
It was broken by . I'll send a fix in a sec.
Sorry & thanks for fixing.


Question: } list := &unstructured.UnstructuredList{} <ins> list.SetRemainingItemCount(entireList.GetRemainingItemCount()) </ins> list.SetResourceVersion(entireList.GetResourceVersion()) <ins> list.SetContinue(entireList.GetContinue()) </ins> list.GetObjectKind().SetGroupVersionKind(listGVK) for i := range entireList.Items { item := &entireList.Items[i]

The fake dynamic client does not support mock pagination or the self link. Add ability to propagate the metadata fields from a mock unstructured list to the served list by the fake lister. Repro linked in the MR x-ref. No response <details</detailsN/A N/A <detailsN/A </details<detailsN/A </details<detailsN/A </details
/sig api-machinery
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: ) const ( <del> errBadCertificate    = "Get .*: remote error: tls: bad certificate" </del> <ins> errBadCertificate    = "Get .*: remote error: tls: (bad certificate|unknown certificate authority)" </ins> errNoConfiguration   = "invalid configuration: no configuration has been provided" errMissingCertPath   = "invalid configuration: unable to read %s %s for %s due to open %s: .*" errSignedByUnknownCA = "Get .*: x509: .*(unknown authority|not standards compliant|not trusted)"

Using the Go 1.21 dev branch, FORCEHOSTGO=y make test fails because the TLS bad certificate error has gotten more specific in Go 1.21. Test should pass. Use the command above with the Go 1.21 dev branch as your in your PATH. Here is the fix: HEAD N/A N/A N/A N/A N/A
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
Thank you very much /priority important-soon /cc The fix is already reported on the description, so this is an easy PR for people willing to contribute /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Thank you very much /priority important-soon /cc 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
/sig architecture
/assign


Question: // is the max character length for the USER itself. Both the DOMAIN and USER have their // own restrictions, and more information about them can be found here: // https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and <del> // https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1 </del> <ins> // https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb726984(v=technet.10) </ins> const ( maxGMSACredentialSpecLengthInKiB = 64 maxGMSACredentialSpecLength      = maxGMSACredentialSpecLengthInKiB * 1024 maxRunAsUserNameDomainLength     = 256 <del> maxRunAsUserNameUserLength       = 21 </del> <ins> maxRunAsUserNameUserLength       = 104 </ins> ) var (

<!-- 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: Currently, the character limit for the usernames set in the field is 20, which is too low, considering that "ContainerAdministrator" is a valid username and it is longer than 20 characters. A user should be able to run containers as Administrator, if needed. What you expected to happen: Users should be able to spawn pods which run as. How to reproduce it (as minimally and precisely as possible): WindowsRunAsUserName feature gate. () Anything else we need to know?: /sig windows /priority important-soon /milestone 1.16 Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- 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! --2. ` /priority important-soon /milestone 1.16 Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: </details
/milestone v1.16


Question: JSON and YAML formats are accepted. <ins> Please refer to the models in https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/HEAD/docs/api-reference/definitions.html to find if a field is mutable. </ins> ``` kubectl replace -f FILENAME ```

The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.


Question: } func TestDescribeDeployment(t *testing.T) { <del> fakeClient := fake.NewSimpleClientset(&appsv1.Deployment{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", }, Spec: appsv1.DeploymentSpec{ Replicas: utilpointer.Int32Ptr(1), Selector: &metav1.LabelSelector{}, Template: corev1.PodTemplateSpec{ Spec: corev1.PodSpec{ Containers: []corev1.Container{ {Image: "mytest-image:latest"}, </del> <ins> labels := map[string]string{"k8s-app": "bar"} testCases := []struct { name    string objects []runtime.Object expects []string }{ { name: "deployment with two mounted volumes", objects: []runtime.Object{ &appsv1.Deployment{ ObjectMeta: metav1.ObjectMeta{ Name:              "bar", Namespace:         "foo", Labels:            labels, UID:               "00000000-0000-0000-0000-000000000001", CreationTimestamp: metav1.NewTime(time.Date(2021, time.Month(1), 1, 0, 0, 0, 0, time.UTC)), }, Spec: appsv1.DeploymentSpec{ Replicas: utilpointer.Int32Ptr(1), Selector: &metav1.LabelSelector{ MatchLabels: labels, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", Labels:    labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Image: "mytest-image:latest", VolumeMounts: []corev1.VolumeMount{ { Name:      "vol-foo", MountPath: "/tmp/vol-foo", }, { Name:      "vol-bar", MountPath: "/tmp/vol-bar", }, }, }, }, Volumes: []corev1.Volume{ { Name:         "vol-foo", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, { Name:         "vol-bar", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, }, }, }, }, }, &appsv1.ReplicaSet{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar-001", Namespace: "foo", Labels:    labels, OwnerReferences: []metav1.OwnerReference{ { Controller: utilpointer.BoolPtr(true), UID:        "00000000-0000-0000-0000-000000000001", }, }, }, Spec: appsv1.ReplicaSetSpec{ Replicas: utilpointer.Int32Ptr(1), Selector: &metav1.LabelSelector{ MatchLabels: labels, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", Labels:    labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Image: "mytest-image:latest", VolumeMounts: []corev1.VolumeMount{ { Name:      "vol-foo", MountPath: "/tmp/vol-foo", }, { Name:      "vol-bar", MountPath: "/tmp/vol-bar", }, }, }, }, Volumes: []corev1.Volume{ { Name:         "vol-foo", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, { Name:         "vol-bar", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, }, }, }, }, Status: appsv1.ReplicaSetStatus{ Replicas:          1, ReadyReplicas:     1, AvailableReplicas: 1, </ins> }, }, }, <ins> expects: []string{ "Name:               barnNamespace:          foo", "CreationTimestamp:  Fri, 01 Jan 2021 00:00:00 +0000", "Labels:             k8s-app=bar", "Selector:           k8s-app=bar", "Replicas:           1 desired | 0 updated | 0 total | 0 available | 0 unavailable", "Image:        mytest-image:latest", "Mounts:n      /tmp/vol-bar from vol-bar (rw)n      /tmp/vol-foo from vol-foo (rw)", "OldReplicaSets:  <none>", "NewReplicaSet:   bar-001 (1/1 replicas created)", "Events:          <none>", }, }, { name: "deployment during the process of rolling out", objects: []runtime.Object{ &appsv1.Deployment{ ObjectMeta: metav1.ObjectMeta{ Name:              "bar", Namespace:         "foo", Labels:            labels, UID:               "00000000-0000-0000-0000-000000000001", CreationTimestamp: metav1.NewTime(time.Date(2021, time.Month(1), 1, 0, 0, 0, 0, time.UTC)), }, Spec: appsv1.DeploymentSpec{ Replicas: utilpointer.Int32Ptr(2), Selector: &metav1.LabelSelector{ MatchLabels: labels, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", Labels:    labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Image: "mytest-image:v2.0", VolumeMounts: []corev1.VolumeMount{ { Name:      "vol-foo", MountPath: "/tmp/vol-foo", }, { Name:      "vol-bar", MountPath: "/tmp/vol-bar", }, }, }, }, Volumes: []corev1.Volume{ { Name:         "vol-foo", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, { Name:         "vol-bar", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, }, }, }, }, Status: appsv1.DeploymentStatus{ Replicas:            3, UpdatedReplicas:     1, AvailableReplicas:   2, UnavailableReplicas: 1, }, }, &appsv1.ReplicaSet{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar-001", Namespace: "foo", Labels:    labels, UID:       "00000000-0000-0000-0000-000000000001", OwnerReferences: []metav1.OwnerReference{ { Controller: utilpointer.BoolPtr(true), UID:        "00000000-0000-0000-0000-000000000001", }, }, }, Spec: appsv1.ReplicaSetSpec{ Replicas: utilpointer.Int32Ptr(2), Selector: &metav1.LabelSelector{ MatchLabels: labels, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", Labels:    labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Image: "mytest-image:v1.0", VolumeMounts: []corev1.VolumeMount{ { Name:      "vol-foo", MountPath: "/tmp/vol-foo", }, { Name:      "vol-bar", MountPath: "/tmp/vol-bar", }, }, }, }, Volumes: []corev1.Volume{ { Name:         "vol-foo", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, { Name:         "vol-bar", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, }, }, }, }, Status: appsv1.ReplicaSetStatus{ Replicas:          2, ReadyReplicas:     2, AvailableReplicas: 2, }, }, &appsv1.ReplicaSet{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar-002", Namespace: "foo", Labels:    labels, UID:       "00000000-0000-0000-0000-000000000002", OwnerReferences: []metav1.OwnerReference{ { Controller: utilpointer.BoolPtr(true), UID:        "00000000-0000-0000-0000-000000000001", }, }, }, Spec: appsv1.ReplicaSetSpec{ Replicas: utilpointer.Int32Ptr(1), Selector: &metav1.LabelSelector{ MatchLabels: labels, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "foo", Labels:    labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Image: "mytest-image:v2.0", VolumeMounts: []corev1.VolumeMount{ { Name:      "vol-foo", MountPath: "/tmp/vol-foo", }, { Name:      "vol-bar", MountPath: "/tmp/vol-bar", }, }, }, }, Volumes: []corev1.Volume{ { Name:         "vol-foo", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, { Name:         "vol-bar", VolumeSource: corev1.VolumeSource{EmptyDir: &corev1.EmptyDirVolumeSource{}}, }, }, }, }, }, Status: appsv1.ReplicaSetStatus{ Replicas:          1, ReadyReplicas:     0, AvailableReplicas: 1, }, }, &corev1.Event{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar-001", Namespace: "foo", }, InvolvedObject: corev1.ObjectReference{ APIVersion: "apps/v1", Kind:       "Deployment", Name:       "bar", Namespace:  "foo", UID:        "00000000-0000-0000-0000-000000000001", }, Type:    corev1.EventTypeNormal, Reason:  "ScalingReplicaSet", Message: "Scaled up replica set bar-001 to 2", Source: corev1.EventSource{ Component: "deployment-controller", }, FirstTimestamp: metav1.NewTime(time.Now().Add(-10 * time.Minute)), }, &corev1.Event{ ObjectMeta: metav1.ObjectMeta{ Name:      "bar-002", Namespace: "foo", }, InvolvedObject: corev1.ObjectReference{ APIVersion: "apps/v1", Kind:       "Deployment", Name:       "bar", Namespace:  "foo", UID:        "00000000-0000-0000-0000-000000000001", }, Type:    corev1.EventTypeNormal, Reason:  "ScalingReplicaSet", Message: "Scaled up replica set bar-002 to 1", Source: corev1.EventSource{ Component: "deployment-controller", }, FirstTimestamp: metav1.NewTime(time.Now().Add(-2 * time.Minute)), }, }, expects: []string{ "Replicas:           2 desired | 1 updated | 3 total | 2 available | 1 unavailable", "Image:        mytest-image:v2.0", "OldReplicaSets:  bar-001 (2/2 replicas created)", "NewReplicaSet:   bar-002 (1/1 replicas created)", "Events:n", "Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set bar-001 to 2", "Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set bar-002 to 1", }, </ins> }, <del> }) d := DeploymentDescriber{fakeClient} out, err := d.Describe("foo", "bar", DescriberSettings{ShowEvents: true}) if err != nil { t.Errorf("unexpected error: %v", err) </del> } <del> if !strings.Contains(out, "bar") || !strings.Contains(out, "foo") || !strings.Contains(out, "Containers:") || !strings.Contains(out, "mytest-image:latest") { t.Errorf("unexpected out: %s", out) </del> <ins> for _, testCase := range testCases { t.Run(testCase.name, func(t *testing.T) { fakeClient := fake.NewSimpleClientset(testCase.objects...) d := DeploymentDescriber{fakeClient} out, err := d.Describe("foo", "bar", DescriberSettings{ShowEvents: true}) if err != nil { t.Errorf("unexpected error: %v", err) } for _, expect := range testCase.expects { if !strings.Contains(out, expect) { t.Errorf("expected to find "%s" in:n %s", expect, out) } } }) </ins> } }

Create a deployment as described in section, and run 'kubectl describe deploy/testWhat happened: shows , while shows the current replicaset infomation What you expected to happen: shows the current replicaset infomation, while shows How to reproduce it (as minimally and precisely as possible): Create a deployment as follows, and wait its pod started. Then, run 'kubectl describe deploy/test Anything else we need to know?: Environment: Kubernetes version (use ): kubectl of 1.14+(I did not try older versions) 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 cli
/assign
Ok, can confirm here. With the old code, during a rollout the data is shown at OldReplicaSets (both the old and new RS) while with the patch during the rollout the NewReplicaSet contains the net one and the Old the old one ( obvious here) while the old exists. I'll make some more tests here and check if is there anything else in your PR that needs better verification, otherwise wer can follow with it! Thank you!
/triage accepted


Question: import ( "context" "fmt" <ins> "io/ioutil" </ins> "path" "time"

"[] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance]" is failing consistently for Windows 1909 on GCE, but it's passing for 2019. Likely one of the containers it depends on hasn't been rebuilt as multi-arch? Failure message from
/sig windows cc
More useful output from build- Seems the container doesn't work on 1909. cc
/sig windows
This test is also failing on for Windows 1903.
see
Ah, thanks, I searched k/k for an existing issue but didn't think to search windows-testing. I posted a follow-up there.
Hi. It is a known issue, I've also reported it a while back:
, do you have push right to the ` manifest list to include the newer Windows OS versions. Basically, the commands are: docker manifest create docker manifest push --purge
/kind failing-test
I tried running this but got: I looked into the project and noticed and as owners. Are you able to assist?
/assign
docker manifest push Pushed ref with digest: sha256:ec76696da5a660a02bbfd304549d6e09d8c9fe48f2d4efe642f26cb1e46a6bde Pushed ref with digest: sha256:7c4ee446a647fdf8988672ae5e685cb66d53d4581e057b02e3a2bad728177f48 Pushed ref with digest: sha256:297cce9134ddaa2c09d91dea7ab7af0e58e06e59858c0311a0770143d144ddf1 sha256:fb9b25770487567c02bf90dd3edea7917323556d1b7ba81ec042ffd5f9effeae
this is fixed. the image manifest is available in
/close
Closing this issue. <detailsIn response to : /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

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: containerd-l2bridge-windows-master containerd-overlay-windows-master Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance] Since when has it been failing: Unknown. Testgrid link: Reason for failure: When creating the container, the following error occurs: Failed: Error: failed to create containerd task: hcsshim::CreateComputeSystem image-pull-test: The container operating system does not match the host operating system. Windows Server 2019 is used in the testing environment, and the image image, and the test is passing in all other jobs that are using docker instead of containerd. But the image has been built at the beggining of 2019, so it's most likely outdated (the Microsoft official images are updated regularly), which could lead to the OS version mismatch. Note that most of the other tests are passing for the containerd jobs, which are using the test images hosted in the image (LTS 2019 and 1809 have the same OS version), and they're always up-to-date. One solution could be to republish the image based on a freshly pulled nanoserver image. Anything else we need to know: /sig windows /sig testing
- is the login/password public so this can be debugged outside of the prow cluster?
- what containerd branch / hash was it built from?
- Some part of my memory thinks this was fixed in upstream containerd/cri. Do you recall any items around this recently?
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


Question: func listDaemonPods(ctx context.Context, c clientset.Interface, ns string, label map[string]string) *v1.PodList { selector := labels.Set(label).AsSelector() <del> options := metav1.ListOptions{LabelSelector: selector.String()} </del> <ins> options := metav1.ListOptions{ LabelSelector: selector.String(), FieldSelector: nonTerminalPhaseSelector.String(), } </ins> podList, err := c.CoreV1().Pods(ns).List(ctx, options) framework.ExpectNoError(err) gomega.Expect(podList.Items).ToNot(gomega.BeEmpty())

master-blocking Conformance - GCE - master - kubetest2Kubernetes e2e suite. ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test ! 2023-06-27 16:43 PDT Kubernetes e2e suite: [It] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] No response /sig cloud-provider /sig apps cc
This is more critical than I expected it starts to fail in other jobs ,%20master ,%20ipvs,%20dual,%20master From the diff the best candidate seems can you PTAL /priority critical-urgent
/assign
anyone from you can please add to this issue?
/triage accepted
I have a proposed fix in . Is there a job I can add?
/remove-kind failing-test /kind flake


Question: for i := 0; i < 3; i++ { framework.Logf("PD Read/Writer Iteration #%v", i) By("submitting host0Pod to kubernetes") <ins> host0Pod = testPDPod([]string{disk1Name, disk2Name}, host0Name, false /* readOnly */, 1 /* numContainers */) </ins> _, err = podClient.Create(host0Pod) framework.ExpectNoError(err, fmt.Sprintf("Failed to create host0Pod: %v", err))

PR moved some PD tests to flaky to resolve issue (and duplicate ). These tests started failing due to PR . is working on a patch to de-flake the tests. This issue is to track the fix and should be closed when: PD tests have been deflaked (verify by running the "" e2e tests back to back for a couple of hours to verify the issue is fixed). flaky label has been removed from the "" tests that were marked flaky in CC
how to watch the submit queue and find if the flake is gone?
I don't know. is there any way can verify whether test is no longer flaky?
I'm not sure what the publicly accessible link for test history is. I took a look for you: Pod Disks should schedule a pod w/ a RW PD shared between multiple containers, write to PD, delete pod, verify contents, and repeat in rapid succession Failed 3 times in the last 30 runs. Stability: 90 % Pod Disks should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession Failed 1 times in the last 30 runs. Stability: 96 % I have a PR pending that enables the new attach/detach controller and I was able to run the tests back to back overnight without any failures. So once that gets merged, we can take a look at moving these tests back.
Something in PD attach/detach affects also 'Dynamic provisioning' e2e test, a PD is still attached to a node ~15 minutes after appropriate pod was deleted and thus deleter can't delete it. From controller log:
please take a look at https://k8s-
thanks so at least one of the flake has a different error than "container not found" In one, the error is
^^ the above seems like a possible bug in exec
^
The error to me indicates that the original container is no longer around as exec can't find the ipc namespace fd. Are we sure the container that we are trying to join is still around?
my memory is rusty but did you have an idea to randomize the container id in this pd test?
see the info here:
Close we will track this with


Question: podsToAdd:    []*v1.Pod{testPods[0]}, }} <del> for _, tt := range tests { cache := newSchedulerCache(ttl, time.Second, nil) for _, podToAssume := range tt.podsToAssume { if err := assumeAndFinishBinding(cache, podToAssume, now); err != nil { t.Errorf("assumePod failed: %v", err) </del> <ins> for i, tt := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { cache := newSchedulerCache(ttl, time.Second, nil) for _, podToAssume := range tt.podsToAssume { if err := assumeAndFinishBinding(cache, podToAssume, now); err != nil { t.Errorf("assumePod failed: %v", err) } </ins> } <del> } for _, podToAdd := range tt.podsToAdd { if err := cache.AddPod(podToAdd); err != nil { t.Errorf("AddPod failed: %v", err) </del> <ins> for _, podToAdd := range tt.podsToAdd { if err := cache.AddPod(podToAdd); err != nil { t.Errorf("AddPod failed: %v", err) } </ins> } <del> } snapshot := cache.Dump() if len(snapshot.Nodes) != len(cache.nodes) { t.Errorf("Unequal number of nodes in the cache and its snapshot. expected: %v, got: %v", len(cache.nodes), len(snapshot.Nodes)) } for name, ni := range snapshot.Nodes { nItem := cache.nodes[name] if !reflect.DeepEqual(ni, nItem.info) { t.Errorf("expect n%+v; got n%+v", nItem.info, ni) </del> <ins> snapshot := cache.Dump() if len(snapshot.Nodes) != len(cache.nodes) { t.Errorf("Unequal number of nodes in the cache and its snapshot. expected: %v, got: %v", len(cache.nodes), len(snapshot.Nodes)) </ins> } <del> } if !reflect.DeepEqual(snapshot.AssumedPods, cache.assumedPods) { t.Errorf("expect n%+v; got n%+v", cache.assumedPods, snapshot.AssumedPods) } </del> <ins> for name, ni := range snapshot.Nodes { nItem := cache.nodes[name] if !reflect.DeepEqual(ni, nItem.info) { t.Errorf("expect n%+v; got n%+v", nItem.info, ni) } } if !reflect.DeepEqual(snapshot.AssumedPods, cache.assumedPods) { t.Errorf("expect n%+v; got n%+v", cache.assumedPods, snapshot.AssumedPods) } }) </ins> } }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign


Question: var _ Interface = new(cadvisorClient) // New creates a cAdvisor and exports its API on the specified port if port > 0. <del> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string) (Interface, error) { </del> <ins> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string, usingLegacyStats bool) (Interface, error) { </ins> client, err := winstats.NewPerfCounterClient() return &cadvisorClient{winStatsClient: client}, err }

<!-- 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: is failing with: What you expected to happen: The cross build should work,. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It looks like this happened in , probably because we don't block the queue on cross :-( xref: /priority failing-test /sig release
Additionally ideally sig-release should for this job.
/assign
, is making a fix and then we'll look at making sure cross blocks PRs it runs against in the future.


Question: "items":[ { "kind":"None", <del> "metadata":{"name":"127.0.0.1"}, </del> <ins> "metadata":{ "name":"127.0.0.1", "labels":{ "kubernetes.io/hostname":"127.0.0.1" } }, </ins> "status":{ "capacity":{"cpu":"4"}, "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]

I love using but I cannot figure out how to print an annotation that contains a special character like or or . This does not work: nor this: nor this: nor this: kubectl get pods tmp--dhpx0 -o jsonpath="{$['metadata']['annotations']['']}" (the last one should work according to what I can find about jsonPath, but doesn't, and anyhow is hard to get shell escaping right for. Need a way to quote a
A use case for this is extracting "created-by" or "init-container" annotations. I've wanted to do both in the last month and fought jsonpath.
FYI, this is possible with go-template. We should still fix the jsonpath though. Similar issue:


Question: # # This entry is a stub of the major version to allow dependency checks to # pass when building Kubernetes using a pre-release of Golang. <del> # TODO: remove this when whe have the go1.23 released and not the rc. # - name: "golang: 1.<major>" #   version: 1.22 #   refPaths: #   - path: build/build-image/cross/VERSION #   - path: hack/lib/golang.sh #     match: minimum_go_version=go([0-9]+.[0-9]+) </del> <ins> - name: "golang: 1.<major>" version: 1.22 refPaths: - path: build/build-image/cross/VERSION - path: hack/lib/golang.sh match: minimum_go_version=go([0-9]+.[0-9]+) </ins> - name: "registry.k8s.io/kube-cross: dependents" <del> version: v1.31.0-go1.23rc2-bullseye.0 </del> <ins> version: v1.31.0-go1.22.5-bullseye.0 </ins> refPaths: - path: build/build-image/cross/VERSION

sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
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
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)


Question: Subsystem:         KubeletSubsystem, Name:              ActiveConfigKey, Help:              "The config source the node is actively using. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
Reopened this issue. <detailsIn response to : /reopen 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
/cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon


Question: eps := sets.NewString() filterCmd := fmt.Sprintf("%s | grep -v '^s*$'", cmd) <ins> framework.Logf("Going to poll %v on port %v at least %v times, with a maximum of %v tries before failing", targetIP, targetPort, minTries, maxTries) </ins> for i := 0; i < maxTries; i++ { stdout, stderr, err := config.f.ExecShellInPodWithFullOutput(config.HostTestContainerPod.Name, filterCmd) if err != nil || len(stderr) > 0 {

What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar


Question: github.com/kr/text v0.1.0 h1:45sCR5RtlFHMR4UwH9sdQ5TC8v0qDQCHnXt+kaKSTVE= github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI= github.com/kylelemons/godebug v0.0.0-20170820004349-d65d576e9348/go.mod h1:B69LEHPfb2qLo0BaaOLcbitczOKLWTsrBG9LczfCD4k= <del> github.com/libopenstorage/openstorage v0.0.0-20170906232338-093a0c388875 h1:s+gZ8/rkYrWgN7xTMUISDw6nspgWyju2OCKmpFBrviQ= github.com/libopenstorage/openstorage v0.0.0-20170906232338-093a0c388875/go.mod h1:Sp1sIObHjat1BeXhfMqLZ14wnOzEhNx2YQedreMcUyc= </del> <ins> github.com/libopenstorage/openstorage v1.0.0 h1:GLPam7/0mpdP8ZZtKjbfcXJBTIA/T1O6CBErVEFEyIM= github.com/libopenstorage/openstorage v1.0.0/go.mod h1:Sp1sIObHjat1BeXhfMqLZ14wnOzEhNx2YQedreMcUyc= </ins> github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de h1:9TO3cAIGXtEhnIaL+V+BEER86oLrvS+kWobKpbJuye0= github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de/go.mod h1:zAbeS9B/r2mtpb6U+EI2rYA5OAXxsYw6wTamcNW+zcE= github.com/lithammer/dedent v1.1.0 h1:VNzHMVCBNG1j0fh3OrsFRkVUwStdDArbgBWoPAffktY=

Found this when trying to see which vendored dependencies does not use a proper tag (and is using a random SHA). The dependency is very old and there have been a lot of updates to it: Looks like the However there does not seem to be anyone around to take care of the portworx plugin. Is it time to deprecate it? is anyone using it? /sig storage
cc ?
/area code-organization
Hello The portworx volume plugin is definitely in use. The portworx volume plugin doesn't need frequent updates since the plugin acts as a simple client to all provisioning calls. In the same view, the vendored openstorage package doesn't need to be updated too. The server side implementation in Portworx handles all the latest Portworx features.
cc:
in that case, can you please update the dependency to a specific tag instead of a random SHA?
/assign updated the title of the issue as well
my request is not for a new release or tag in libopenstorage/openstorage repository. Just to update the SHA we use in our k/k repository to one of the released versions ( ). This is not asking or demanding anything to be done in libopenstorage/openstorage, just that we should update what we use from there (and avoid a random SHA). We are trying to do this for all vendored libraries (one by one … slowly as part of the sig-arch code organization sub project, so it’s not a random request)
/assign
GitHub didn't allow me to assign the following users: lpabon. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
After a chat with - apparently this request is coming across the wrong way I am closing this out as it seems to add a over head /close
Closing this issue. <detailsIn response to : After a chat with - apparently this request is coming across the wrong way /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


Question: grains: node_ip: $MASTER_IP master_ip: $MASTER_IP <ins> publicAddressOverride: $MASTER_IP </ins> network_mode: openvswitch <ins> networkInterfaceName: eth1 </ins> etcd_servers: $MASTER_IP cloud: vagrant cloud_provider: vagrant

The kubelet.service EnvironmentFile /etc/sysconfig/kubelet doesn't exist on my minions.
Some extra information from master and minion-1:
I didn't think we used pki with salt. I wonder why salt is complaining about it. , David Reynolds wrote:
Is it possible this is related to salt's tar option having changed? A fix for that went in earlier today, but I don't know that we fixed vagrant yet...
Something else when I try to ./cluster/kube- This happens for each minion.
I think it's looking for eth0 in that ips list but isn't finding it?
since you're in the maintainers file for vagrant: any ideas?
- not yet, but I can take a look
- just to help debug, was this a fresh cluster you created that was working and then stopped after a push, or was this a fresh cluster that never worked?
It was a cluster that was working, I did a push and it broke. So I tore it down completely and rebuilt a fresh cluster that doesn't work either.
I am actually getting an issue where if I run more than one minion, my salt-minion is no longer able to contact the salt-master. So there is a number of things I need to look into.
So eth0 does not exist on a vagrant box for me, we look to need to use eth1 in a vagrant env.
appears to have introduced the regression on the vagrant env. is causing the issue.
Looking to see if I can specify which network interface to use for the function so we can safely use ips[0][0] when in an environment where the interface is not eth0
Just synced my branch, and found the issue is not limited to vagrant. When I ran hack/dev-build-kube-, I have the same kubeletservicecannotrestart issue due to lack of /var/lib/kubelet/kubernetesauth: But kubernetesauth is not installed: root ls /var/lib/kubelet/kubernetesauth ls: cannot access /var/lib/kubelet/kubernetes_auth: No such file or directory cc/
There are a number of issues, the master is not picking up the right network interface to use for the kube-apiserver to serve the readonly content, think we need a entry for address and publicAddressOverride per the arguments to kube-apiserver.

I don't have much more time to debug this tonight, but there are a number of issues we need to resolve here.
I ran kube- to recreate the cluster, and now /var/lib/kubelet/kubernetesauth is properly installed on nodes, and kubelet is succussfully started without any issue. Looks like we ran into saltcannotupgradeall_files issue we saw before.
- I do not see same behavior on a fresh cluster.
I am referring to gce, not vagrant. I think there are more issues on vagrant. But on gce, fresh cluster don't have issue.
I think I am close to a fix for vagrant.
Submitted a fix. Testing appreciated.
Bringing up a new cluster on vagrant. Will report back in a bit.
Works for me! Fresh cluster build
Works for me too. Awesome work. Thanks!
Derek, do you folks run vagrant e2e? If not maybe I should add that to our jenkins e2e box... --brendan , David Reynolds wrote:
Brendan, If you are willing to add it to your jenkins box that would be appreciated. -- Derek ----- Original Message ----- From: "Brendan Burns" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Wednesday, November 19, 2014 11:45:46 PM Subject: Re: [kubernetes] Kubelet not starting () Derek, do you folks run vagrant e2e? If not maybe I should add that to our jenkins e2e box... --brendan , David Reynolds wrote: Reply to this email directly or view it on GitHub:
The problem with upgrading the cluster is that it references a new file that doesn't exist if you are doing an upgrade. I'm going to check in a default version of that file to make this work and to smooth things over when the check fails.


Question: // Config holds the information needed to build connect to remote kubernetes clusters as a given user type Config struct { <del> v1beta3.TypeMeta `json:",inline"` </del> <ins> // Legacy field from pkg/api/types.go TypeMeta. // TODO(jlowdermilk): remove this after eliminating downstream dependencies. Kind string `json:"kind,omitempty"` // Version of the schema for this config object. APIVersion string `json:"apiVersion,omitempty"` </ins> // Preferences holds general information to be use for cli interactions Preferences Preferences `json:"preferences"` // Clusters is a map of referencable names to cluster configs

has a dependency on pkg/api for , which it embeds in . Is it doing that to take advantage of validation code, or can Config just declare and directly and avoid the dependency?
A quick try (just declaring a in the package) seems to work fine with . I only included those out of habit.
Out of curiosity, is this just for a proper separate of packages or is there some functional issue as well?
mentioned encountering an issue with tests, but it's mostly just for proper separation of packages.
Related: Remove json tags from
See also
Not done:


Question: framework.ExpectNodeHasTaint(cs, nodeName, &testTaint) return &testTaint } <del> // updateNodeResources updates the resource of given node with the given values. func updateNodeResources(c clientset.Interface, nodeName string, memoryAllocatable, cpuAllocatable, memoryCapacity, cpuCapacity int64) error { node, err := c.CoreV1().Nodes().Get(nodeName, metav1.GetOptions{}) framework.ExpectNoError(err) if err != nil { return err } node.Status.Capacity[v1.ResourceMemory] = *resource.NewQuantity(memoryCapacity, resource.BinarySI) node.Status.Capacity[v1.ResourceCPU] = *resource.NewMilliQuantity(cpuCapacity, resource.DecimalSI) node.Status.Allocatable[v1.ResourceMemory] = *resource.NewQuantity(memoryAllocatable, resource.BinarySI) node.Status.Allocatable[v1.ResourceCPU] = *resource.NewMilliQuantity(cpuAllocatable, resource.DecimalSI) _, err = c.CoreV1().Nodes().UpdateStatus(node) return err } </del>

Testgrid: https://k8s- https://k8s- Example: https://k8s- This seems to be related to /sig scheduling /kind failing-test /priority important-soon /cc
/assign RaviSantosh Gudimetla
GitHub didn't allow me to assign the following users: RaviSantosh, Gudimetla. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign RaviSantosh Gudimetla 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
/assign
Looked at the kube-scheduler logs for GCE, seems the feature_gate was enabled. I don't see enabled, will setup the cluster locally to test if this is the issue.
have you been able to look into this? These tests are broken right now for unrelated reasons, but once they get fixed I expect to keep seeing the scheduler failure.
/milestone v1.13
is the one open PR expected to fix the remaining failures we are seeing the release dashboards? If not fixed by this week, these failures will block Beta cut targeted for 11/6.
- Apologies for the delay. Yes, this PR should fix the failure, if not, I will disable this test for now and revert the feature promotion PR associated with this test. Also, I need to rethink, if e2e is an appropriate test scenario to handle this feature or should unit tests/integration suffice. I could not find a test which does something like resizing a node in the existing e2e test suite.
I'm looking at this, and I'm not sure this is going to fix the failures. I'm looking at the tests, and it seems to be setting the node status capacity/allocatable to pretend to be a 12 core machine, and then it tries to allocate a pod on every node such that every node is 50% utilized. It thus tries to allocate a pod of ~ 6 cores on the resized node. But that node still only has 2 cores, so it fails to schedule: I think that's why the test has been failing, at least for the past few runs which I checked.

What I have yet to figure out is how this passed here...
is it safe to rephrase this as a pure test design issue then?
the test still failed on the last . Even though it was a couple of hours after PR merged, I dont see it in the delta changes . I will watch for the next run result. Assuming it still doesnt pass (as pointed out about) we need to figure out what this e2e test failure means and should it block 1.13 Beta0 for next Tuesday. Considering the test did pass very few times since its introduction, this seems like an issue with the test design itself and not the feature. Do you have other tests (unit or integration or different approach to e2e) that can infirm us on the health of thew feature? If those exist and are green we can unblock Beta on those results while you determine the right way to author the e2e. Barring those being present right idea, I think we will have to err on the side of caution and roll back the feature itself before Beta. Either way we need to take a call and submit relevant PRs by tomorrow so we get green CI over the weekend, in time for Beta cut on Tuesday.
This is not a blocker, as I told earlier as well, e2e may not be good avenue for this test. I actually thought more about this problem last day. The problem is I updated the node capacity and I was checking if the node could handle the pod based on the scheduler cache which we get from kubelet. But kubelet on the other side is updating it's node information(like CPU, memory etc) in the API server there by causing a race condition. So, it could pass with a very little chance. So, I will remove this test from e2e. Yes, we have unit tests, that help in validating the feature. I will try to get an integration test but this is not a blocker for feature.
Thanks for the explanation and analysis do you plan on adding more e2e tests later or stick to unit and integration for validating this feature? and to weigh in on the path forward i.e., remove e2e tests for this feature and rely on unit and integration.
- We discussed internally in the sig meeting yesterday and it was decided to have an integration test instead of e2e test.

I plan to add an integration test(which we don't have today) later.
since this PR is actually tracking an enhancement work graduating to Beta in 1.13, it should have been tracked via a corresponding issue in k/enhancements repo in 1.13 timeframe. We are now past Feature freeze for 1.13 and its late to open an issue against it. Also we are missing integration tests for this feature, which we are . Given the above two points and from offline discussions with SIG leads regarding the criticality of this feature going to Beta now vs in 1.14 timeframe, I am asking for it to be punted to 1.14. As AIs Please prepare a PR to remove it from Beta in 1.13 Please open a tracking issue in for 1.14 milestone.


Question: syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } <ins> // DaemonSet should launch a pod on a not ready node with taint notReady:NoExecute. func TestNotReadyNodeDaemonLaunchesPod(t *testing.T) { manager, podControl, _ := newTestController() node := newNode("tainted", nil) setNodeTaint(node, nodeNotReady) node.Status.Conditions = []v1.NodeCondition{ {Type: v1.NodeReady, Status: v1.ConditionFalse}, } manager.nodeStore.Add(node) ds := newDaemonSet("simple") manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } // DaemonSet should launch a pod on an unreachable node with taint unreachable:NoExecute. func TestUnreachableNodeDaemonLaunchesPod(t *testing.T) { manager, podControl, _ := newTestController() node := newNode("tainted", nil) setNodeTaint(node, nodeUnreachable) node.Status.Conditions = []v1.NodeCondition{ {Type: v1.NodeReady, Status: v1.ConditionUnknown}, } manager.nodeStore.Add(node) ds := newDaemonSet("simple") manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } </ins> // DaemonSet should launch a pod on an untainted node when the pod has tolerations. func TestNodeDaemonLaunchesToleratePod(t *testing.T) { manager, podControl, _ := newTestController()

When writing DaemonSets we decided that they shouldn't be deleted by NodeController in case of Node problems. Now that we're moving to using taints and taint-based evictions (NC will just taint Nodes and the rest will be done by generic taint-eviction mechanism) we need to add infinite toleration for those taints to DaemonSets to keep this behavior. cc
Off the top of my head, I think the best way to implement this is to modify the , to special-case DaemonSet pods and add infinite tolerationSeconds to them. (See definition of field in the API for how to do this.) do you think you can do this? It should be a simple change. cc/ BTW the feature Marek described will be alpha in 1.6, but nobody will be able to use it (without breaking DaemonSet) unless this request is implemented. So the 1.6 milestone tag is appropriate.
Why wouldn't the daemon set controller special case that?
Yeah, I guess that's probably better - have the DaemonSet controller create pods with the toleration.
I can do this, and yes, in the DaemonSet controller.


Question: if !found { return api.PodTerminated, nil } <ins> if pod.CurrentState.Info == nil { return api.PodWaiting, nil } </ins> running := 0 stopped := 0 unknown := 0

to reproduce: create vagrant kubernetes with 5 minions. try guest book example on it. After provisioning: then kill 10.245.2.6 minion: then we get: Nothing changes even after waiting for significant period of time. Please note, that while redis-master wasn't in replication controller and it's not expected for it to restart, it's still wrongfully marked as Running.


Question: klog.V(7).Infof("startRequest(%#+v) => fsName=%q, distMethod=%#+v, plName=%q, numQueues=%d", rd, selectedFlowSchema.Name, selectedFlowSchema.Spec.DistinguisherMethod, plName, numQueues) req, idle := plState.queues.StartRequest(ctx, &rd.WorkEstimate, hashValue, flowDistinguisher, selectedFlowSchema.Name, rd.RequestInfo, rd.User, queueNoteFn) if idle { <del> cfgCtlr.maybeReapLocked(plName, plState) </del> <ins> cfgCtlr.maybeReapReadLocked(plName, plState) </ins> } return selectedFlowSchema, plState.pl, false, req, startWaitingTime, flowDistinguisher }

Two flakes recently: They fail with error like: or /assign
/sig scalability
In logs I have found the following slow calls: It's a bug that we use exempt priority level for clusterloader: I created It's quite worrisome that APF handler takes 1s for exempt request.
I checked a APF code and I think the flow for exempt requests is: genericfilters.WithPriorityAndFairness() workEstimate := workEstimator.EstimateWork(r) fcIfc.Handle() cfgCtlr.startRequest() () looks for matching flowschemas in cfgCtrl.flowSchemas returns for exempt for other requests it calculates sha256 for flowDistinguisher and queues request req.Finish updates metrics calls execFn updates headers handler.ServeHTTP which stops the timer for priorityandfairness For me, the most likely reason for slowness is lock contention on We know that the test is super cpu-intensive in that part and other requests are e.g. calculating sha256 keeping that lock. A potential improvement would be to change this lock to RWLock or return the lock before starting calculating sha256 (if we believe that this is the most expensive operation there). /cc
/assign
I think the lock-contention is even worse than what you wrote, as e.g.: is happening under this lock (which is also dispatching requests). I will take a deeper look later this week, but I think that switching to RWLock might do the job without any invasive changes.
may trigger the execution of some requests that were waiting, but they are not executed in the same goroutine. Yes, I think changing that Mutex to a RWMutex would be an easy way to greatly reduce contention.
I agree switching to RWMutex is likely to help a lot, if that's not enough I think with a little work we could e.g. switch to s.
(perhaps because that's what my code originally did? Reviewers thought the retirement dance was too tricky.)
/triage accepted /priority important-soon I will work on the fix.
/sig api-machinery
Wow! Thanks a lot for rapid help here! Let's wait for the next test run to see if it helped. /reopen
Reopened this issue. <detailsIn response to : Wow! Thanks a lot for rapid help here! Let's wait for the next test run to see if it helped.

/reopen 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
Yes, can you please report the filter latency regardless of whether it is bad or good? I would like to know how much of a difference that PR made.
Sure, will report the latency change in both cases.
I compared (the one where we saw issue) (first with the lock improvements) I tried to find requests that: use exempt PL (so shouldn't be throttled) has fl_priorityandfairness, key which means that priority and fairness filter took more than 100ms Sample matching request: In the old run, I see ~6k such requests, with the locking improvements there are no such requests. The latency of PATCH jobs seems to improve significantly: ! So overall it looks great. The only worrisome metric I see is that actual P&F throttling for other requests has grown: With locking improvements: ! Old: ! E.g. 'node-high' has now throttling latency of ~1.5s in spikes where in the previous test run it was more like ~800ms. I don't think the lock improvements touched this directly. I expect that this is either: per-test variance (if we rerun the old run again we would see different throttling latencies as well) we throttle exempt requests less (as expected) giving less resources to other requests. Anyway, I don't think this change is meaningful as per-test latency aggregates for PATCH nodes/status and PUT leases (the most common requests in node-high) look ~same as previously: ! ! I think we can close this for now as the issue seems to be resolved. Thanks a lot for your help here! /close
Closing this issue. <detailsIn response to : I compared In the old run, I see ~6k such requests, with the locking improvements there are no such requests. The latency of PATCH jobs seems to improve significantly: ! ! ! I expect that this is either: ! ! /close </details
: thanks for reporting!


Question: }, }, StopError:       nil, <del> ExpectedActions: []string{"get", "list", "get", "update", "watch", "delete"}, </del> <ins> ExpectedActions: []string{"get", "list", "get", "update", "get", "delete"}, </ins> }, { Name: "OverlappingError",

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle

30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
I'm pretty sure, those amount of failure are related to: (I don't know why yet).

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}


Question: // // // <del> // // // // // </del> // This must be line #50. var _ = ginkgo.Describe("e2e", func() {

periodic-kubernetes-unit-test-ppc64le TestCleanup Probably since it was merged in https://k8s- No response The error from build log trace is: Please go through the above job for complete build log. /sig testing
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
This test has been constantly failing in our environment and not just flaking. Also, We see it still failing even after your fix for is the job that ran after merge of
^^
cc
This is a data race in the control plane setup. cc
So yes, this is different from the failure that I ran into. It's still a flake (races don''t always go wrong), but apparently the conditions in your jobs are so that it always triggers.
I'll take care of this /assign
At first glance it looks like access to in lacks protection by a mutex. But why are and racing with each other in different goroutines, and why is called first?
in some executions it seems that it just timeouts, no races I think that the problem is that this environment is under resourced and this test is not able to boot the apsierver , that may explain the race and why Stop is racing with Start
Should we perhaps make this unit test run only on amd64 architectures, with the rationale a) that it isn't architecture-dependent and thus testing it in one unit test job is sufficient and b) that it is an expensive test that stresses slower architectures too much?
the apiserver times out starting up, I think we can make it lighter with it sound fair to me, since we use etcd and it is only guaranteed to build do you want to make the honors? or should I?
Can you do it because we probably want both and you know best how to explain the patch above in the commit message?

I thought about this twice, and I don't think we should tune the tests for running on constrained environments, this is a slippery slope, this environment is clearly constrained , there are also other issues reporting timeouts in this environment ... we should not tune test just to pass The skip based on etcd not supported may be reasonable though
Met this again when running , see
this is for the ppc64le specific problem, we should open a new one for this test it seems there were 2 occurrences more
For tracking, opened a new issue here


Question: // plugin to use standard input. This is kept here in order to keep all of the exec configuration // together, but it is never serialized. // +k8s:conversion-gen=false <del> StdinUnavailable bool </del> <ins> StdinUnavailable bool `json:"-"` </ins> // StdinUnavailableMessage is an optional message to be displayed when the exec authenticator // cannot successfully run this exec plugin because it needs to use standard input and // StdinUnavailable is true. For example, a process that is already using standard input to // read user instructions might set this to "used by my-program to read user instructions". // +k8s:conversion-gen=false <del> StdinUnavailableMessage string </del> <ins> StdinUnavailableMessage string `json:"-"` </ins> } var _ fmt.Stringer = new(ExecConfig)

yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.


Question: func (s *store) Delete(ctx context.Context, key string, out runtime.Object, preconditions *storage.Preconditions, validateDeletion storage.ValidateObjectFunc) error { v, err := conversion.EnforcePtr(out) if err != nil { <del> panic("unable to convert output object to pointer") </del> <ins> return fmt.Errorf("unable to convert output object to pointer: %v", err) </ins> } key = path.Join(s.pathPrefix, key) return s.conditionalDelete(ctx, key, out, v, preconditions, validateDeletion)

Remove panic in , please return error instead following .
/sig api-machinery /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig api-machinery /good-first-issue 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
/assign
Please also add some log if returns error
/remove-kind bug /kind cleanup


Question: function start_kubedns { if [[ "${ENABLE_CLUSTER_DNS}" = true ]]; then cp "${KUBE_ROOT}/cluster/addons/dns/kube-dns/kube-dns.yaml.in" kube-dns.yaml <del> sed -i -e "s/{{ pillar['dns_domain'] }}/${DNS_DOMAIN}/g" kube-dns.yaml sed -i -e "s/{{ pillar['dns_server'] }}/${DNS_SERVER_IP}/g" kube-dns.yaml </del> <ins> ${SED} -i -e "s/{{ pillar['dns_domain'] }}/${DNS_DOMAIN}/g" kube-dns.yaml ${SED} -i -e "s/{{ pillar['dns_server'] }}/${DNS_SERVER_IP}/g" kube-dns.yaml </ins> # TODO update to dns role once we have one. # use kubectl to create kubedns addon ${KUBECTL} --kubeconfig="${CERT_DIR}/admin.kubeconfig" --namespace=kube-system create -f kube-dns.yaml

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: After running (on master branch), a new file named left as a surprise. and the file is not matched by git ignore so it's tracked by git which is really disturbing. I tried to find out where it's created but failed. Any one has a context w/ it? Environment: OS (e.g. from /etc/os-release): Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASEX8664 x86_64
/sig instrumentation
the only piece of code in local-up-cluster that touches the file is
can't reproduce this. Two questions: Can you see this everytime? What is the SHA of the commit on master when you tried this? Can check with that too.
finally i realize that the cause is command is built receiving different flags between Linux and OSX. on Linux, you'll find that for linux sed the is explained as: '--in-place[=SUFFIX]' This option specifies that files are to be edited in-place. GNU 'sed' does this by creating a temporary file and sending output to this file rather than to the standard output.(1). so the is optional. but for OSX, it is: Edit files in-place, saving backups with the specified extension. If a zero-length extension is given, no backup will be saved. It is not recommended to give a zero- length extension when in-place editing files, as you risk corruption or partial content in situations where disk space is exhausted, etc. the difference is that on OSX, flag is requiring a variable , so when we're using on OSX in the script: the which is supposed to be received as a flag will be a suffix for the backup file. then the magic happened.will raise a fix for this. /assign
linking the difference between and


Question: framework.ConformanceIt("should function for node-pod communication: udp [LinuxOnly] [NodeConformance]", func() { config := e2enetwork.NewCoreNetworkingTestConfig(f, true) for _, endpointPod := range config.EndpointPods { <del> config.DialFromNode("udp", endpointPod.Status.PodIP, e2enetwork.EndpointUDPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) </del> <ins> err := config.DialFromNode("udp", endpointPod.Status.PodIP, e2enetwork.EndpointUDPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) if err != nil { framework.Failf("Error dialing UDP from node to pod: %v", err) } </ins> } }) })

What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar


Question: t.Fatalf("%d:, error writing to stderr: %v", i, err) } stderr.Close() <del> select { case <-clientStderrReadDone: case <-time.After(10 * time.Millisecond): t.Fatalf("%d: timed out waiting for client to read stderr", i) } </del> <ins> <-clientStderrReadDone </ins> } else if stderr != nil { t.Fatalf("%d: stderr: expected nil: %#v", i, stderr) }

this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.


Question: "os/exec" "path" "path/filepath" <del> "runtime" </del> "strconv" "strings" "sync"

What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.


Question: package oom import ( <ins> "os" </ins> "github.com/opencontainers/runc/libcontainer/cgroups" "testing"

<!-- 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: What you expected to happen: The test should pass How to reproduce it (as minimally and precisely as possible): I think the key here is being on a linux host with cgroupsv2 enabled. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig node
/assign
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


Question: // if >0 existing slices, mark all but 1 for deletion. slices.toDelete = existingSlices[1:] <del> // generated slices must mirror all endpoints annotations but EndpointsLastChangeTriggerTime compareAnnotations := cloneAndRemoveKeys(endpoints.Annotations, corev1.EndpointsLastChangeTriggerTime) </del> <ins> // generated slices must mirror all endpoints annotations but EndpointsLastChangeTriggerTime and LastAppliedConfigAnnotation compareAnnotations := cloneAndRemoveKeys(endpoints.Annotations, corev1.EndpointsLastChangeTriggerTime, corev1.LastAppliedConfigAnnotation) </ins> compareLabels := cloneAndRemoveKeys(existingSlices[0].Labels, discovery.LabelManagedBy, discovery.LabelServiceName) // Return early if first slice matches desired endpoints, labels and annotations totals = totalChanges(existingSlices[0], desiredSet)

If I modify a custom endpoint, the kubectl annotation is mirrored to the generated endpoint slice Since the kubect last-applied-configuration tracks the status of the object, it shouldn't be mirrored since it doesn't apply to the generated object a custom endpoint an update on any of the fields the generated endpoint slice annotations /sig network
ping
if we agree this is a bug, the fix is just and adding some tests of course :)
Thanks for catching this! Agree this is a bug that we should fix.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
Hey, I'm on it!
Hi While I have made the update mentioned in the above comment, I feel a bit lost on where to add/update tests. I understand that I probably shouldn't raise a PR without trying to add a few tests for this issue. So could you possibly guide me to the correct files(s) I should be looking into where the annotations for updated EndpointSlices are being tested?
Hey I think the easiest place to add tests might be here: You could add another test case where the Endpoints object had this label and then ensure that label was not copied over to an EndpointSlice.
Alright I'll check out these tests. Thank you!
/assign


Question: package e2enode import ( <ins> "context" </ins> "fmt" "os" "os/exec" "os/user" <ins> "sync" </ins> "time" "k8s.io/klog" <ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apimachinery/pkg/util/sets" internalapi "k8s.io/cri-api/pkg/apis" runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Unless disabled, the tests will prepull all images when running. They do so using the . I think there's the opportunity to improve the runtime of the test suite by prepulling the images in parallel. Why is this needed: Its always nicer to have faster tests :) Specifically for users running locally, it's nice to have the image prepull occur as quick as possible. That being said, we should also be cognizant of any tradeoffs associated with prepulling the images in parallel. If the code is substantially more complex, we would need a large improvement in test speed to justify it. I'm hopeful this discussion could be had once we have a proof of concept diff (which I think should be fairly minimal effort to create).
/sig node
I think this could be a good first issue for someone looking to get involved with contributing to sig-node :) Please post if you plan on working on it, so that there aren't multiple people tackling it.
I'd be interested! I'm looking for a first issue and think this would be a good one
Wonderful! Want to reach out to me on Kubernetes slack? I'm on there too :)
:wave: hiya ! Are you still thinking you could be interested in working on this? Lmk if so, and we can chat about next steps? If not, perhaps I'll open it back up to a newcomer looking for a first commit?
I'm going to open this back up for someone looking for a first commit. Lmk if you're still interest in getting sig-node, and happy to find an issue for you :)
Opening this back up for folks :) I'm happy to mentor whoever picks this up if that'd be helpful :) Ping me on k8s-slack, where I'm also
Can you assign this to meI'd be interested!
/assign
Awesome - feel free to reach out on k8s-slack if you have questions, or if you already have a plan, feel free to tag me in the pull request. Thanks :)
/lifecycle active /priority important-longterm


Question: StabilityLevel: metrics.ALPHA, }, ) <del> SchedulingAlgorithmPreemptionEvaluationDuration = metrics.NewHistogram( </del> <ins> DeprecatedSchedulingAlgorithmPreemptionEvaluationDuration = metrics.NewHistogram( </ins> &metrics.HistogramOpts{ <del> Subsystem:      SchedulerSubsystem, Name:           "scheduling_algorithm_preemption_evaluation_seconds", Help:           "Scheduling algorithm preemption evaluation duration in seconds", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, </del> <ins> Subsystem:         SchedulerSubsystem, Name:              "scheduling_algorithm_preemption_evaluation_seconds", Help:              "Scheduling algorithm preemption evaluation duration in seconds", Buckets:           metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel:    metrics.ALPHA, DeprecatedVersion: "1.20.0", </ins> }, ) <del> BindingLatency = metrics.NewHistogram( </del> <ins> DeprecatedBindingLatency = metrics.NewHistogram( </ins> &metrics.HistogramOpts{ <del> Subsystem:      SchedulerSubsystem, Name:           "binding_duration_seconds", Help:           "Binding latency in seconds", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, </del> <ins> Subsystem:         SchedulerSubsystem, Name:              "binding_duration_seconds", Help:              "Binding latency in seconds", Buckets:           metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel:    metrics.ALPHA, DeprecatedVersion: "1.20.0", </ins> }, ) PreemptionVictims = metrics.NewHistogram(

Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. This can be done by setting in each of the two metrics opts. Changing the name of the metric variable to be prefixed with "Deprecated" is useful as well. /help /sig scheduling
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. /sig scheduling 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
/assign
/kind deprecation


Question: if kubelettypes.IsCriticalPod(attrs.Pod) { return lifecycle.PodAdmitResult{Admit: true} } <del> // the node has memory pressure, admit if not best-effort if hasNodeCondition(m.nodeConditions, v1.NodeMemoryPressure) { </del> <ins> // Conditions other than memory pressure reject all pods nodeOnlyHasMemoryPressureCondition := hasNodeCondition(m.nodeConditions, v1.NodeMemoryPressure) && len(m.nodeConditions) == 1 if nodeOnlyHasMemoryPressureCondition { </ins> notBestEffort := v1.PodQOSBestEffort != v1qos.GetPodQOS(attrs.Pod) if notBestEffort { return lifecycle.PodAdmitResult{Admit: true}

<!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check and the . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via --In the code below, kubelet rejects pods with QOS type guaranteed when under disk pressure, but when kubelet is also under memory pressure, those pods are accepted, is this behavior expected? Why is that?
/area kubelet /sig node
See this comment: It came with commit
you can find an answer from the proposal doc:
thank you ! I think current code is not following the eviction design of condition. the proposal is: but the code is: , guaranteed pods are not rejected any more. seems to be working fine though, maybe here's the reason: PS: above content can be found in