Question: } func (v *visitor) getDescription(value string) string { <del> if len(v.lastDescribe.lastContext.text) > 0 { return strings.Trim(v.lastDescribe.text, """) + " " + strings.Trim(v.lastDescribe.lastContext.text, """) + " " + strings.Trim(value, """) </del> <ins> tokens := []string{} for _, describe := range v.describes { tokens = append(tokens, describe.text) if len(describe.lastContext.text) > 0 { tokens = append(tokens, describe.lastContext.text) } } tokens = append(tokens, value) trimmed := []string{} for _, token := range tokens { trimmed = append(trimmed, strings.Trim(token, """)) </ins> } <del> return strings.Trim(v.lastDescribe.text, """) + " " + strings.Trim(value, """) </del> <ins> return strings.Join(trimmed, " ") </ins> } var (

What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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


Question: cmd.Flags().StringVar(&o.SinceTime, "since-time", o.SinceTime, i18n.T("Only return logs after a specific date (RFC3339). Defaults to all logs. Only one of since-time / since may be used.")) cmd.Flags().DurationVar(&o.SinceSeconds, "since", o.SinceSeconds, "Only return logs newer than a relative duration like 5s, 2m, or 3h. Defaults to all logs. Only one of since-time / since may be used.") cmd.Flags().StringVarP(&o.Container, "container", "c", o.Container, "Print the logs of this container") <del> cmd.Flags().BoolVar(&o.Interactive, "interactive", o.Interactive, "If true, prompt the user for input when required.") cmd.Flags().MarkDeprecated("interactive", "This flag is no longer respected and there is no replacement.") </del> cmdutil.AddPodRunningTimeoutFlag(cmd, defaultPodLogsTimeout) cmd.Flags().StringVarP(&o.Selector, "selector", "l", o.Selector, "Selector (label query) to filter on.") return cmd

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: says: What you expected to happen: Don't suggest that -- as it doesn't actually do that when used. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: (This was reported in but that issue was closed) Environment: Kubernetes version (use ): (This is indeed head from today) Cloud provider or hardware configuration: macOS OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools:Others:
/sig cli
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: deps = [ "//pkg/api:go_default_library", "//pkg/api/service:go_default_library", <ins> "//pkg/api/v1:go_default_library", "//pkg/client/record:go_default_library", </ins> "//pkg/proxy:go_default_library", "//pkg/proxy/healthcheck:go_default_library", "//pkg/types:go_default_library",

When kube-proxy fails to open a nodeport, it gives up setting up the rest of the iptables rules for the service. Leaving the service not usable. Cannot even use it with clusterIP. Kube-proxy only logs this error in . No useful information can be retrieved with kubectl. Need to record a event at least.
Ideally would the changes be removed and then reported back? Is there a preferred log or place to return the error?
the event maybe a better solution; as other port maybe success.
Need to surface the problem somewhere. An event seems okay
, there's and in ; should we reuse it or create new recorders for ?
Just reuse it. After all, it is within the same component. Are you going to submit a PR?
sure, my pleasure.
Great! Thanks! Let me know when the PR is ready.


Question: for i := range pips { pip := pips[i] <del> if pip.Tags != nil && (pip.Tags)["service"] != nil && *(pip.Tags)["service"] == serviceName { </del> <ins> if serviceOwnsPublicIP(&pip, clusterName, serviceName) { </ins> // We need to process for pips belong to this service pipName := *pip.Name if wantLb && !isInternal && pipName == desiredPipName {

<!-- 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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign


Question: if !ok { cacheSize = f.Options.DefaultWatchCacheSize } <ins> // depending on cache size this might return an undecorated storage </ins> ret.Decorator = genericregistry.StorageWithCacher(cacheSize) } return ret, nil

Currently we signal undecorated storage by simply affecting the undecoratedStorage to the decorator. This is a blocker for kubernetes/enhancements as we need to enable watch cache for events (which currently hardcoded and not configurable) cc /assign /sig api-machinery


Question: "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", "//staging/src/k8s.io/client-go/util/testing:go_default_library", "//staging/src/k8s.io/legacy-cloud-providers/aws:go_default_library", <ins> "//vendor/github.com/stretchr/testify/assert:go_default_library", </ins> "//vendor/k8s.io/klog:go_default_library", ], )

<!-- 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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign


Question: } scaleTest := &HPAContainerResourceScaleTest{ initPods:                    1, <del> totalInitialCPUUsage:        250, perContainerCPURequest:      500, </del> <ins> totalInitialCPUUsage:        125, perContainerCPURequest:      250, </ins> targetCPUUtilizationPercent: 20, minPods:                     1, maxPods:                     5, firstScale:                  3, firstScaleStasis:            stasis, <del> cpuBurst:                    700, </del> <ins> cpuBurst:                    500, </ins> secondScale:                 5, sidecarStatus:               e2eautoscaling.Enable, sidecarType:                 e2eautoscaling.Idle,

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- Kubernetes e2e suite.[sig-autoscaling] [Feature:HPA] Horizontal pod autoscaling (scale resource: CPU) [Serial] [Slow] ReplicaSet with idle sidecar (ContainerResource use case) Should not scale up on a busy sidecar with an idle application Kubernetes e2e suite.[sig-autoscaling] [Feature:HPA] Horizontal pod autoscaling (scale resource: CPU) [Serial] [Slow] ReplicaSet with idle sidecar (ContainerResource use case) Should scale from 1 pod to 3 pods and from 3 to 5 on a busy application with an idle sidecar container August 13th 2021 pr: feature is not turned on in api server /sig windows /assign /triage accepted
kubernetes-sigs/windows-testing enables this test for windows but the current number of CPU's require for this new test is higher due to each pod requiring 500m cpu. the existing tests work on the current infra with the same number for CPU requests. Since the new tests adds a second container for each pod it double the amount of cpu required and causes the pod to go to pending and the test to timeout:


Question: "The request is invalid", DefaultErrorExitCode, }, <ins> // invalid error that that includes a message but no details { &errors.StatusError{metav1.Status{ Status: metav1.StatusFailure, Code:   http.StatusUnprocessableEntity, Reason: metav1.StatusReasonInvalid, // Details is nil. Message: "Some message", }}, "The request is invalid: Some message", DefaultErrorExitCode, }, // webhook response that sets code=422 with no reason { &errors.StatusError{metav1.Status{ Status:  "Failure", Message: `admission webhook "my.webhook" denied the request without explanation`, Code:    422, }}, `Error from server: admission webhook "my.webhook" denied the request without explanation`, DefaultErrorExitCode, }, // webhook response that sets code=422 with no reason and non-nil details { &errors.StatusError{metav1.Status{ Status:  "Failure", Message: `admission webhook "my.webhook" denied the request without explanation`, Code:    422, Details: &metav1.StatusDetails{}, }}, `Error from server: admission webhook "my.webhook" denied the request without explanation`, DefaultErrorExitCode, }, // source-wrapped webhook response that sets code=422 with no reason { AddSourceToErr("creating", "configmap.yaml", &errors.StatusError{metav1.Status{ Status:  "Failure", Message: `admission webhook "my.webhook" denied the request without explanation`, Code:    422, }}), `Error from server: error when creating "configmap.yaml": admission webhook "my.webhook" denied the request without explanation`, DefaultErrorExitCode, }, // webhook response that sets reason=Invalid and code=422 and a message { &errors.StatusError{metav1.Status{ Status:  "Failure", Reason:  "Invalid", Message: `admission webhook "my.webhook" denied the request without explanation`, Code:    422, }}, `The request is invalid: admission webhook "my.webhook" denied the request without explanation`, DefaultErrorExitCode, }, </ins> }) }

kubectl apply displays different errors in v1.21 (and 1.22) vs v1.23 (and above) for the same webhook response, with the error message in v1.23 not being helpful at all. For example, if a webhook returns a status with code is not equal to / the and fields are not populated In v1.21.0, we see the following error. This is a helpful error message with plenty of context. In v1.23.5, for the same webhook status, we'll see: This is not helpful at all. To get an equivalent helpful error message in v1.23.5 Make a webhook return a status with code with or not populated, or not equivalent to . Looking at the code, it looks like this was a consequence of Since this PR was introduced in v1.23, this issue would exist for v1.22 as well. kubectl first checks whether the error message is (in both and ) The definition of was changed in . In 1.21 (and 1.22) just reason "Invalid". Given that the webhook status does not include a , the is executed and kubectl shows a helpful error message. In 1.23 (and above) if OR if the status code is , which is true for the webhook status. Since it’s true, this is executed. is nil, so we just see the response. This error message is not helpful. We should probably update how kubectl handles "invalid" errors and ensure that they display the field too (instead of just restricting to check the ). Verified with v1.21.0 and v1.23.5. Have not verified this for v1.22, but it should also affect v1.22 due to the above reasons. N/A 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 cli
/assign
Hi So this purely a client-side issue, right?

The server is still sending back the exact same response/data structure? Thanks!
FYI, I posted in Kube slack related to this. We were hoping to alter our webhook behavior based on the originating user agent by passing the into the Go context given to our webhook server's request handler. However, it appears we are not able to access the originating user-agent info. As indicated in the Slack thread: In other words, the sooner this issue is fixed, the better.
checked with nikhita offline, will reroute the issue /assign /unassign
fix open in


Question: // getVolCount returns the number of volumes in use by the kubelet. // It does so by counting the number of directories prefixed by the given portal and IQN. func getVolCount(dir, portal, iqn string) (int, error) { <del> // The topmost dirs are named after the ifaces, e.g., iface-default or iface-127.0.0.1:3260:pv0 </del> <ins> // For FileSystem volumes, the topmost dirs are named after the ifaces, e.g., iface-default or iface-127.0.0.1:3260:pv0. // For Block volumes, the default topmost dir is volumeDevices. </ins> contents, err := ioutil.ReadDir(dir) if err != nil { <ins> if os.IsNotExist(err) { return 0, nil } </ins> return 0, err }

<!-- 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: Deletion of a Pod with an ISCSI volume in mode results in an error during , leaving an ISCSI target logged into on the kubelet node despite the target being unused. In my case, the ISCSI Target server enforces a single session per LUN, which blocks the Pod from starting on another Node in the cluster. What you expected to happen: For the kubelet to issue a logout request for the given target once the refcounter hits zero. How to reproduce it (as minimally and precisely as possible): Have an ISCSI Target server Create a target/LUN that contains an ext4 filesystem. Have a Node configured as an ISCSI Initiator capable of logging into the those targets. Create a Pod on the Node that includes an volume referring the LUN, using (rather than ) mode. minimally: Delete the Pod Wait for the Pod to be destroyed and the related ISCSI block device to be removed. on the Node will show the target is still logged in Kubelet error: Anything else we need to know?: Environment: Kubernetes version (use ): 1.16.2 Cloud provider or hardware configuration: Reproducible on a bare metal (Intel NUC) lab and DigitalOcean DOKS. OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): 4.15 (NUC) / 4.19 (DigitalOcean) Install tools: Ubuntu package /sig storage


Question: klog.ErrorS(err, "Failed to initialize logging") os.Exit(1) } <ins> cliflag.PrintFlags(cleanFlagSet) </ins> // construct a KubeletServer from kubeletFlags and kubeletConfig kubeletServer := &options.KubeletServer{

When starting the Kubelet with , the Kubelet begins with unstructured logging and then transitions to structured logging: I expect the Kubelet to have structured logging through the startup lifecycle. Kubernetes version (use ): master [] 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:
/triage accepted /sig node
Is it possible that these components are not yet migrated? I don't think or are on structured logging yet.
/cc
It's true tha and and is not yet log structured, At least I don't see it in the PR that exists
This bug is related to JSON implementation, not structured logging. Moment that logging format configuration is applied happens late in component bootstrap process. (EDIT: changed the "Configuration of JSON" to "Moment that logging format configuration is applied")
If so, is it related to this PR ? This PR changes the from component-base/logs to the component-base/config
No, your PR is not related. As a configuration of JSON I meant the moment the configuration is applied and klog switches to use different format. This is done exactly when particular component calls . Fixing this issue should be done by changing component bootstrap process in a way that prioritizes configuring logging over any other configuration.
Thanks, I get it
/assign
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/milestone v1.22
/sig instrumentation /wg structured-logging
Hey there ( Bug-Triage here , Given the fact that the code freeze for this release already started, I´d like to suggest moving this issue to the next milestone. wdyt?
Due to v1.22 code freeze, I'm moving this issue to the next release. /milestone v1.23
This needs to be fixed in kubelet. Those log messages that occur in text format should be moved to a point during init where logging is initialized.
Hey there ( Bug-Triage here , Just want to make sure this issue is still on track for the 1.23?

Hey what's the current status of init logs after your recent improvements? Is there anything left to do here?
No, this is not fixed. is still being called before . The behavior is a bit different, though: while previously it used the wrong default log format, now it uses the wrong default log level and therefore those messages are not printed. I'd also like to clarify one thing: the "Flag ... has been deprecated, will be removed in a future version" messages are printed by pflag to stderr. Those are not normal log messages and no matter what we do with logging, they will always be plain text.
The fix is easy. Whether there's anyone willing to approve a PR is a different question...
/milestone v1.24
We can still fix this in 1.23. PR is here:


Question: {Manager: "e", Operation: metav1.ManagedFieldsOperationUpdate, Time: parseTimeOrPanic("2003-01-01T01:00:00Z")}, }, }, <ins> { name: "sort drops nanoseconds", managedFields: []metav1.ManagedFieldsEntry{ {Manager: "c", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 1, time.UTC)}}, {Manager: "a", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 2, time.UTC)}}, {Manager: "b", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 3, time.UTC)}}, }, expected: []metav1.ManagedFieldsEntry{ {Manager: "a", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 2, time.UTC)}}, {Manager: "b", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 3, time.UTC)}}, {Manager: "c", Operation: metav1.ManagedFieldsOperationUpdate, Time: &metav1.Time{time.Date(2000, time.January, 0, 0, 0, 0, 1, time.UTC)}}, }, }, </ins> } for _, test := range tests {

What happened: On a resource with managedFields populated, a no-op patch modified the serialization order of managedFields. What you expected to happen: No-op patches do not result in a write to etcd. How to reproduce it (as minimally and precisely as possible): contains: the initial ADDED event from kubectl MODIFIED events from kube-controller-manager one MODIFIED event corresponding to the kubectl patch (from resourceVersion 1704 in 1.txt to resourceVersion 1718 in 2.txt) shows the kubectl and kube-controller-manager managed field sets swapped order: second patch was a no-op ( is empty) Anything else we need to know?: This was easiest to reproduce with server-side apply enabled at 100% /assign
/sig api-machinery
/wg apply
Can you print the before/after fieldmanager? I can't quite figure out what the actual values are. The code that sorts these lists is located
updated to unified diff and attached:
If you explicitly set the field manager to something unique, does it happen every time?
hm, no, it's definitely an ordering swap
is not sorted properly, since should come before .
We seem to also sort it in a second place:
Theory: the first time it goes through, the time is accurate to the nanosecond; the second time, it's accurate to the second
Yeah OK I'm pretty sure that's it, both times are the same second. Serialization drops the fractional part.


Question: // When the deployment status and its underlying resources reach the desired state, we're done if deployment.Status.Replicas == deployment.Spec.Replicas && <del> deployment.Status.UpdatedReplicas == deployment.Spec.Replicas && deploymentutil.GetReplicaCountForReplicaSets(oldRSs) == 0 && deploymentutil.GetReplicaCountForReplicaSets([]*extensions.ReplicaSet{newRS}) == deployment.Spec.Replicas { </del> <ins> deployment.Status.UpdatedReplicas == deployment.Spec.Replicas { </ins> return true, nil } return false, nil

https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Happened on a presubmit run in . Previous issues for this test:
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s-

Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes

e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}


Question: gvr("storage.k8s.io", "v1", "csistoragecapacities"): { Stub:             `{"metadata": {"name": "csc-12345-3"}, "storageClassName": "sc1"}`, ExpectedEtcdPath: "/registry/csistoragecapacities/" + namespace + "/csc-12345-3", <del> ExpectedGVK:      gvkP("storage.k8s.io", "v1beta1", "CSIStorageCapacity"), </del> }, // --

The override in can be removed in Kubernetes v1.25 because then the oldest supported kube-apiserver for downgrades will be v1.24 which will understand the v1 format. Also need to adapt See and Code cleanup...
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig storage
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 /lifecycle frozen


Question: expected: new(spec.Schema), }, { <ins> name: "nullable required", in: &apiextensions.JSONSchemaProps{ Type: "object", Properties: map[string]apiextensions.JSONSchemaProps{ "a": { Nullable: true, Type:     "string", }, "b": { Nullable: true, Type:     "string", }, "c": { Type: "string", }, }, Required: []string{"a", "c"}, }, expected: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "a": {}, "b": {}, "c": { SchemaProps: spec.SchemaProps{ Type: []string{"string"}, }, }, }, Required: []string{"c"}, }, }, }, { name: "nullable required additionalProperties", in: &apiextensions.JSONSchemaProps{ Type: "object", AdditionalProperties: &apiextensions.JSONSchemaPropsOrBool{ Schema: &apiextensions.JSONSchemaProps{ Nullable: true, Type:     "string", }, }, Required: []string{"a", "c"}, }, expected: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, AdditionalProperties: &spec.SchemaOrBool{ Allows: true, Schema: &spec.Schema{}, }, }, }, }, { </ins> name: "title", in: &apiextensions.JSONSchemaProps{ Title: testStr,

When doing in an OpenShift cluster with a nullable field being required (compare ) and of value null, one gets:
cc
is there a way to also fix the faulty kubectl validation in 1.18.x?


Question: var failureMessage string jobHaveNewFailure := failed > job.Status.Failed <ins> exceedsBackoffLimit := jobHaveNewFailure && (int32(previousRetry)+1 > *job.Spec.BackoffLimit) </ins> <del> // check if the number of failed jobs increased since the last syncJob if jobHaveNewFailure && (int32(previousRetry)+1 > *job.Spec.BackoffLimit) { </del> <ins> if exceedsBackoffLimit || pastBackoffLimitOnFailure(&job, pods) { // check if the number of pod restart exceeds backoff (for restart OnFailure only) // OR if the number of failed jobs increased since the last syncJob </ins> jobFailed = true failureReason = "BackoffLimitExceeded" <del> failureMessage = "Job has reach the specified backoff limit" </del> <ins> failureMessage = "Job has reached the specified backoff limit" </ins> } else if pastActiveDeadline(&job) { jobFailed = true failureReason = "DeadlineExceeded"

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating a job with and , the pod with the configuration included below continued to restart and was never marked as failed: What you expected to happen: We expected only 2 attempted pod restarts before the job was marked as failed. The pod kept restarting and was never set to failed, remained active. How to reproduce it (as minimally and precisely as possible): Create the above job and observe the number of pod restarts. Anything else we need to know?: The flag works as expected when . Environment: Kubernetes version (use ): 1.8.0 using minikube
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I think this is because for , kubelet will try to restart failed pod in place, and the pod status will be even the container is failed to run, so jobcontroller get a illusion as the pod is still running. Here's my naive thoughts: for short-term to avoid this, add a , for long-term we need consider how to recognize and count this kind of Pod as failed pod. cc
Just ran into the issue as well. It might be useful to amend the documentation to warn about the fact that won't be effective if is chosen as restart policy. At least, it wasn't obvious to me and I didn't catch any relevant note in the docs. Happy to do a quick PR if that's a desirable short-term action. For Pods failing as reported in this issue, what's the difference in behavior between a restart policy and a hypothetical scenario where is respected by ? Anything other than failing Pods being replaced by newly created ones in the former case vs. existing Pods being restarted in the latter?
For OnFailure, the failed Pod will restart on the same kubelet host, so emptyDir/hostPath is still there, for Never the failed Pod got delete and a replacement will create on another(may be the same) kubelet host, if the Pod use emptyDir/hostPath to store some tmp data, the tmp data may be lost.

For Pod don't use emptyDir/hostPath, I think there's no much difference for usage( will involve controller, apiserver, scheduler to do some work as it needs to create a replacement, backoffLimit policy will avoid bad jobSpec & container cause to create too many replacement consume control plane bandwidth).
Might it be a reasonable idea to move the parameter into the Pod? I'd think it could prove valuable to have an upper bound on the restarts on Pods themselves independently of Jobs, and it may solve the "how does the Cronjob controller determine that the limit has been reached" problem more elegantly if the Pod's state automatically transitions to failed once the limit is hit. WDYT?
can anyone tell me if I set the Never and the back off to 3 will it try a restart 3 times? this is very confusing
yes, it will. In fact, setting it to is the only way right now to have a back off limit be applied and effective.
I should mention that my statement is based on Kubernetes 1.8. I don't know if any fixes possibly made it into the upcoming 1.9. Then again, if there were, this issue should have been updated or at least referenced.
this is not working for a cronjob job spec (i am running 1.8.6) in the picture i still get new pods when i kill the previous on (5 created 3 should have been created and the job should have failed) any idea how to get this to actually work? !
what's your spec's ? I don't see it in your manifest.
every minute just for testing
Aren't you risking then that restarting jobs from a failed schedule and those from a succeeding schedule might be overlapping? How does it look like when you set the interval to, say, 10 minutes?
same result with 10 minutes interval
I ran a simplified version of your manifest against my Kubernetes 1.8.2 cluster with the command field replaced by so that every run fails, the schedule set to every 5 minutes, and the back-off limit reduced to 2. Here's my manifest: Initially, I get a series of three failing pods: Then it takes pretty much 5 minutes for the next batch to start up and fail: Interestingly, I only get two new containers instead of three.

The next batch though comes with three again: and so does the final batch I tested: Apart from the supposed off-by-one error, things seem to work for me.
Maybe you can double-check using my manifest?
In the we've stated it should work for both restart policies, I've addressed the problem in It counts pod's restartCount, if overall (iow. all containers in all pods) number exceeds backoff limit the job will fail.
I think the backoffLimit doesn't work at all. My kubernetes version is 1.10.3
See .
NAME READY STATUS RESTARTS AGE job-backofflimit-2-9n74x 0/1 Error 0 34s job-backofflimit-2-bt796 0/1 Error 0 1m job-backofflimit-2-fgktc 0/1 Error 0 49s job-backofflimit-2-gfhlx 0/1 Error 0 1m job-backofflimit-2-gzd54 0/1 ContainerCreating 0 8s job-backofflimit-2-ljlpx 0/1 Error 0 1m job-backofflimit-2-p5fxm 0/1 Error 0 1m job-backofflimit-2-w6s5d 0/1 Error 0 21s apiVersion: batch/v1 kind: Job metadata: name: job-backofflimit-2 spec: backoffLimit: 2 template: spec: containers: name: job-with-python2 image: restartPolicy: Never v1.10.4
9 has the same problem. My cluster is 1.9.6, and i run into the same issue


Question: unified := libcontainercgroups.IsCgroup2UnifiedMode() if unified { <del> libcontainerCgroupConfig.Path = m.buildCgroupUnifiedPath(cgroupConfig.Name) </del> <ins> libcontainerCgroupConfig.Path = cgroupConfig.Name.ToCgroupfs() </ins> } else { libcontainerCgroupConfig.Paths = m.buildCgroupPaths(cgroupConfig.Name) }

<!-- 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: is created on a cgroup2 host What you expected to happen: Such directory should not be created How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 with Install moby/moby with containerd/containerd and opencontainers/runc Install kubernetes-sigs/kind . This version uses as the base image. Run with Run Run to drop into the shell of the node The following directories are unexpectedly created. (No process seems to belong to these groups actually) Environment: (See above)
cc
/sig node


Question: creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <ins> name: system:certificates.k8s.io:certificatesigningrequests:nodeclient rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/nodeclient verbs: - create - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/selfnodeclient verbs: - create - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </ins> name: system:discovery rules: - nonResourceURLs:

/kind feature From: Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like. I'm asking because it's already duplicated twice for two early adopters: I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles?
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism.
You could individually revoke this role from the group and stop renewals without disrupting regular operation
I can definitely see myself revoking a binding from to multiple specific bindings in case of a compromise. Anyway, this issue is more "should we create these by default or not". I've already mentioned my opinion.
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer.
Perfect, that's exactly my proposal. I'll go ahead and make this change...
/assign
are you working on this or should I send a PR?


Question: github.com/ThalesIgnite/crypto11 v1.2.5/go.mod h1:ILDKtnCKiQ7zRoNxcp36Y1ZR8LBPmR2E23+wTQe/MlE= github.com/davecgh/go-spew v1.1.0 h1:ZDRjVQ15GmhC3fiQ8ni8+OwkZQO4DARzQgrnXU1Liz8= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= <del> github.com/go-logr/logr v1.2.4 h1:g01GSCwiDw2xSZfjJ2/T9M+S6pFdcNtFYsp+Y43HYDQ= </del> github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q= github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q= github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=

Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?


Question: BeforeEach(func() { c = f.ClientSet <ins> // Use node labels to restrict the pods to be assigned only to the // nodes we observe initially. nodeLabels = make(map[string]string) nodeLabels["kubelet_cleanup"] = "true" </ins> nodes := framework.GetReadySchedulableNodesOrDie(c) numNodes = len(nodes.Items) nodeNames = sets.NewString() // If there are a lot of nodes, we don't want to use all of them // (if there are 1000 nodes in the cluster, starting 10 pods/node // will take ~10 minutes today). And there is also deletion phase. <del> // // Instead, we choose at most 10 nodes and will constraint pods // that we are creating to be scheduled only on that nodes. </del> <ins> // Instead, we choose at most 10 nodes. </ins> if numNodes > maxNodesToCheck { numNodes = maxNodesToCheck <del> nodeLabels = make(map[string]string) nodeLabels["kubelet_cleanup"] = "true" </del> } for i := 0; i < numNodes; i++ { nodeNames.Insert(nodes.Items[i].Name)

https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite} Previous issues for this test:
Most pods failed the predicate. do you mind taking a look since you modified the test to run in a large-cluster?
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
- I'm reassigning back to you since there are a bunch of other failures in small suites. I will debug the large cluster failure in the background.
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s.

{Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
Any updates? CC
The main problem is that the test gets a list of nodes at the beginning, and then creates a RC with N*10 pods, where N is the number of nodes. The test holds on to the initial node list and queries individual kubelet at the /runningPods endpoint to see all pods are running. Here comes the problem. For some reason, the initial list only includes 2 nodes, even though the cluster has 3 (non-master) nodes. The test did not check the pods (/runningPods) on the third node at all, and therefore can never find all pods created by the RC. Test creating 20 pods because it saw only two nodes, and it repeatedly checking those two nodes: The third node () actually existed and pods got scheduled on it: I am not sure yet why the test didn't get 3 nodes at the beginning, and whether the tests started before the cluster became ready.
The kubectl test "should remove all the taints with the same key off a node" adds taint to the node, causing the node to be temporarily ruled out in the cleanup test. I'll patch the cleanup test to avoid hitting this scenario, but I think the the kubectl test could interfere with other tests as well.
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}
https://k8s- Failed: [] kubelet [] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. {Kubernetes e2e suite}


Question: health kubernetes __PILLAR__DNS__DOMAIN__ in-addr.arpa ip6.arpa { pods insecure <ins> upstream </ins> fallthrough in-addr.arpa ip6.arpa ttl 30 }

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [Slow][Serial] Since when has it been failing: Failing since 6/10 at 16:58. . Decent chance that the failure is due to Testgrid link: Reason for failure: /cc /priority critical-urgent /kind failing-test /milestone v1.15 /cc
This is blocking the release /cc
I noticed in the it thinks it's testing 1.16 alpha:
/assign
should fix it. Sorry for the mess-up!


Question: const klogWrapperDepth = 4 func (klogWrapper) Info(args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, args...) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, args...) } </ins> } func (klogWrapper) Infoln(args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, fmt.Sprintln(args...)) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, fmt.Sprintln(args...)) } </ins> } func (klogWrapper) Infof(format string, args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, fmt.Sprintf(format, args...)) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, fmt.Sprintf(format, args...)) } </ins> } func (klogWrapper) Warning(args ...interface{}) {

What happened: we are running apiserver with loglevel 1. However, we are seeing still quite much logs coming from apiserver. ~1800 rows/hour in empty cluster (3 masters, so one apiserver making ~600 rows/hour) Example: What you expected to happen: I expect that if we run apiserver with loglevel 1 we should only see log rows that we are interested of and are important. As I see it, these log rows are not really important and should not be visible. How to reproduce it (as minimally and precisely as possible): put apiserver to loglevel 1 and check the log files after that. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20.2 Cloud provider or hardware configuration: openstack OS (e.g: ): debian buster Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others: /kind bug
/sig api-machinery
/assign /triage accepted
and
Any update on this? This makes debugging more painful. There's a lot of noise. cc
the problem is that these log rows are not coming from this repository. Instead these are coming from for instance is coming from ... which means that it does not matter what loglevel that lib has, it will be always printed still. they have changed logging stuff in latest grpc-go and there are some new env variables but no idea can those still be ignored. perhaps not
I don't think GRPC logs klog style lines on its own?, wherever we have the logging adapter we could handle this on our end.
Our shim should probably map GCPC info =V(N) for some N 1.
I found similar issue with PR I think it could solve this issue also.
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-contributor-experience at . /lifecycle stale
still an issue after update to etcd 3.5.0 and latest grpc in
is there a recommended way to quiet the etcd client logs with the new logging setup in 3.5.0?

potential solution in
Do you understand the source of this logs ? From the high-level glance they might be a syndrome / optimization opportunity: -3.5. configures clientv3 to use 'roundrobin' balancer by default: is it aware decision of api-server to override it to 'pick_first' ? Or the logs are from pre-3.4 and the 3.5 spams with different messages ? assume each of this log-lines is somewhat related to creation of clientv3 object instances (or at least connection management within each client, that do not share the connections pool). Taking in consideration that mTLS shandhake on connection is computationally costly, there might be an area for perf improvement.
/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
Integration with third party logging should be in scope of SIG Instrumentation and WG structured logging. /sig instrumentation /wg structured-logging
the API server sets up the etcd client here, and doesn't override options like that: The specific messages in the description were from an older etcd client, the messages were different in 3.5.0, but still spammy the issue with excessive logging is resolved. If we want a different issue to track log integration, let's open one specifically for that purpose. /close
Closing this issue. <detailsIn response to : is it aware decision of api-server to override it to 'pick_first' ? Or the logs are from pre-3.4 and the 3.5 spams with different messages ? 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
It seems I should upgrade kubernetes version to 1.22 to solve this problem...


Question: /* Release: v1.9 Testname: Pod Lifecycle, post start http hook <del> Description: When a post start handler is specified in the container lifecycle using a HttpGet action, then the handler MUST be invoked after the start of the container. A server pod is created that will serve http requests, create a second pod with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </del> <ins> Description: When a post start handler is specified in the container lifecycle using a HttpGet action, then the handler MUST be invoked after the start of the container. A server pod is created that will serve http requests, create a second pod on the same node with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </ins> */ framework.ConformanceIt("should execute poststart http hook properly [NodeConformance]", func() { lifecycle := &v1.Lifecycle{

<!-- 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 --k8s-e2e-ltsc2019-containerd-flannel-sdnoverlay-master [] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestart http hook properly [NodeConformance] [Conformance] [] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart http hook properly [NodeConformance] [Conformance] Note: the tests have been excluded until they are fixed. In the case of multinode clusters, the http server pod and the test cluster can spawn on different nodes, which can be problematic for poststart / prestop hooks, as they are executed by the kubelet itself, and the cross-node lifecycle hook might fail (according to the [Kubernetes network model], it is not mandatory for kubelet to be able to access pods on a different node). However, that is not always the case, different Networking setups allow cross-node communication between kubelet and pods, which means that the above tests are passing properly (for example: ), which begs the question if this behaviour should be universal or not, especially since the tests are marked as , which would imply that it should work in all cases. [Kubernetes network model]: links to appreciated links to specific failures in spyglass appreciated Slack: /sig testing /sig networking /sig windows <!-- Please see the deflaking doc () for more guidance! --
/sig network /sig node /area conformance /assign /priority critical-urgent /cc This is important since affects conformance and defines the networking behaviour for the poststart/ prestop hooks
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig node /sig conformance /assign /priority critical-urgent /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
i'd personally let folks have first dibs on what we need to do here. Though from the name of the test itself, it seems like the test is NOT a sig-network test :)
Indeed, it does not have any tag in its name, but the tests rely on networking and on how CNIs work.

As I've stated above, it's not a problem for flannel sdnbridge, but it is for flannel sdnoverlay; other CNIs might have a similar issue too.
because the network is not a thing :) let´s tag the sig owner then /sig node I think that the key here is to decide if kubelet should be able to access pod in other nodes, and based on the link Claudiu is part of the Kubernetes networking model. I saw users that doesn't want kubelet to access even the pods on same host, so I think that is legit to say kubelet MAY reach pods in other nodes but not MUST ... but I'm not familiar with the to fully understand the context. If kubelet "may" reach pods in the other nodes, the test must only test lifecycle hooks for pods in the same node as the kubelet under test, right?
This is correct. The model also says: "For those platforms that support Pods running in the host network (e.g. Linux): pods in the host network of a node can communicate with all pods on all nodes without NAT" I believe that Windows host network is not supported, right?
Right, and there are specific tests that checks that exact scenario you've mentioned: However, the flaky tests I've mentioned in the issue require kubelet to be able to dial-in into a webserver pod for a different pod's poststart / prestop HTTP lifecycle hooks. There are couple of things regarding this: of all, in order to ensure kubelet would be able to run the HTTP lifecycle hooks, we'd have to make sure both pods are on the same node, as that is a supported scenario, according to the Kubernetes Network Model. I have sent a PR for this above. Alternatively, a Cluster IP could probably work as well, but IMO, ensuring that both pods end up on the same node is simpler and easier to clean up. , it's interesting that those HTTP lifecycle hook tests work on different networking setups, without any pods having HostNetwork enabled, even though you've mentioned they should (e.g.: Linux / Windows with flannel l2bridge, and even Linux with flannel overlay). Now, my question is: is this behaviour a feature, or a bug, especially since the tests are marked as `?

oh, I missed that part, so in Linux kubelet must be able to communicate with pods on all nodes (becuase it is running in the hostnetwork) If that is correct, it seems that one solution is to keep the test for Linux and tag it as LinuxOnly, and a new test for WindowsOnly that only spawn the pods under test in the same node EDIT Discussed in sig-net meeting , no clear answer... can be kubelet considered as a hostnetwork pod?
For the purposes of testing, I don't mind forcing the pods onto the same node., but let's document the heck out of that at the code-site?
correct but it will be supported once HostProcess containers are merged in 1.22: Only in Overlay networks (ie Flannel where these tests are flaking) does the pod have to be on the same node. It doesn't require host network mode and these tests are . I would be more inclined to disable this test for Windows Overlay test setups and have a sig-windows test for the overlay functionality. I would also question if the lifecycle hooks only running on the same node is useful and if it should just be documented that it doesn't work in the Windows Overlay setup.
is looking at test PRs from SIG Node. I will let sig-net triage this issue
Next steps on this?
/triage accepted
We still haven't merged this: I also had this, but it has been decided to be blocked:
requires conformance approval, at this point I think that has to be postponed to 1.23 right, since that behavior is not required, we shouldn't test it, because is legit to fail and having a test for something that can fail can create confusion :smile:


Question: # Capture local require/replace directives before running any go commands that can modify the go.mod file local require_json="${local_tmp_dir}/require.json" local replace_json="${local_tmp_dir}/replace.json" <del> go mod edit -json | jq -r ".Require // [] | sort | .[] | select(${require_filter})" > "${require_json}" go mod edit -json | jq -r ".Replace // [] | sort | .[] | select(${replace_filter})" > "${replace_json}" </del> <ins> go mod edit -json  | jq -r ".Require // [] | sort | .[] | select(${require_filter})"  > "${require_json}" go mod edit -json  | jq -r ".Replace // [] | sort | .[] | select(${replace_filter})"  > "${replace_json}" </ins> # 1a. Ensure replace directives have an explicit require directive <del> jq -r '"-require (.Old.Path)@(.New.Version)"' < "${replace_json}" | xargs -L 100 go mod edit -fmt </del> <ins> jq -r '"-require (.Old.Path)@(.New.Version)"' < "${replace_json}"  | xargs -L 100 go mod edit -fmt </ins> # 1b. Ensure require directives have a corresponding replace directive pinning a version <del> jq -r '"-replace (.Path)=(.Path)@(.Version)"' < "${require_json}" | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Old.Path)=(.New.Path)@(.New.Version)"' < "${replace_json}" | xargs -L 100 go mod edit -fmt </del> <ins> jq -r '"-replace (.Path)=(.Path)@(.Version)"' < "${require_json}"  | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Old.Path)=(.New.Path)@(.New.Version)"' < "${replace_json}"  | xargs -L 100 go mod edit -fmt </ins> # 2. Propagate root replace/require directives into staging modules, in case we are downgrading, so they don't bump the root required version back up for repo in $(kube::util::list_staging_repos); do pushd "staging/src/k8s.io/${repo}" >/dev/null 2>&1 <del> jq -r '"-require (.Path)@(.Version)"' < "${require_json}" | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Path)=(.Path)@(.Version)"' < "${require_json}" | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Old.Path)=(.New.Path)@(.New.Version)"' < "${replace_json}" | xargs -L 100 go mod edit -fmt </del> <ins> jq -r '"-require (.Path)@(.Version)"' < "${require_json}"  | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Path)=(.Path)@(.Version)"' < "${require_json}"  | xargs -L 100 go mod edit -fmt jq -r '"-replace (.Old.Path)=(.New.Path)@(.New.Version)"' < "${replace_json}"  | xargs -L 100 go mod edit -fmt </ins> popd >/dev/null 2>&1 done # 3. Add explicit require directives for indirect dependencies <del> go list -m -json all | jq -r 'select(.Main != true) | select(.Indirect == true) | "-require (.Path)@(.Version)"'          | xargs -L 100 go mod edit -fmt </del> <ins> go list -m -json all  | jq -r 'select(.Main != true) | select(.Indirect == true) | "-require (.Path)@(.Version)"'  | xargs -L 100 go mod edit -fmt </ins> # 4. Add explicit replace directives pinning dependencies that aren't pinned yet <del> go list -m -json all | jq -r 'select(.Main != true) | select(.Replace == null)  | "-replace (.Path)=(.Path)@(.Version)"' | xargs -L 100 go mod edit -fmt </del> <ins> go list -m -json all  | jq -r 'select(.Main != true) | select(.Replace == null)  | "-replace (.Path)=(.Path)@(.Version)"'  | xargs -L 100 go mod edit -fmt </ins> } function group_replace_directives() {

I ran update- Not to see a ton of errors Kubernetes version (use ): HEAD of master
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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 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 architecture (code organization / dependencies) /sig testing (hack scripts)
/triage accepted


Question: "net/http" "net/http/httptest" "reflect" <ins> "strings" </ins> "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.


Question: "net" "os" "path" <ins> "sync" </ins> "time" "google.golang.org/grpc"

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I'm running into a test failure during "make test". To get more output and to avoid issue , I am using: What you expected to happen: The test should pass. How to reproduce it (as minimally and precisely as possible): It happens for me only when running all tests, but then it happens reliably. When limiting the test run with , it works. The failing calls are not surprising, because got unlinked after binding to it. Those might come from 's : it removes everything in the socket dir, which happens to be . For comparison, here's a successful run: Anything else we need to know?: I'm wondering whether it is guaranteed that different tests in the same .go file run serialized. Does anyone know for sure? I'm asking because all tests in use the same socket directory and thus would conflict with each other if they were to run in parallel. Note that the and calls in the failed test are for different pids. I've not checked whether those are truly different processes (as in fork+exec) or worker threads (clone). Environment: Kubernetes version (use ): master branch, commit OS (e.g. from /etc/os-release): Debian Stretch (9.0) Kernel (e.g. ): 4.9.65-3+deb9u2
After fixing the /tmp dir handling with PR I can no longer reproduce this issue. It might be worth keeping this issue open nevertheless, because the issue has not been explained completely and there might be some remaining problem lurking somewhere.
I think you originally wrote this test. Perhaps you can comment here and comment on PR ?
/cc This test has been re-written multiple times, I'll take a look ASAP :)
/sig node
Will take a look ASAP.
I experienced the same. What's interesting is I can get it to pass when running the devicemanager suite, but only about half the time.
/area hw-accelerators
Thanks a lot for reporting the issue! I think your analysis is right. Looks like the problem is because the devicemanager unit tests are interfering with each other. I will make a change to have each unit test in the file to use a separate test tmp dir.
I'm not exactly sure why, though.

Do they really run in parallel? According to my understanding of testing.Parallel, one has to explicitly request parallel execution, and the tests don't do that. When they run sequentially, then it isn't obvious why the tests interfere and thus using per-test socket dirs would be just a band-aid. Please have a look at PR , it has such a change.
Ah sorry I didn't realize you were already working on a fix. I think go test by default run tests in parallel, so we need to make sure each unit test is self contained. That also explains why you hit this problem more easily when running more tests. I think we perhaps need to modify setup() to make sure each newly created manager uses a separate test dir. Maybe you can take a look at my WIP change and see whether you can merge some of its changes into PR ?
I suggest you take a look at the documentation: On Fri, 9 Feb 2018, 22:34 Jiaying Zhang, <:
On Sat, 2018-02-10 at 05:31 +0000, Vikas Choudhary (vikasc) wrote: True, but which unit tests run concurrently? To answer that, I re-read the "testing" documentation and ran a quick experiment. That confirmed that individual tests inside the same test binary run sequentially. A test function has to explicitly call t.Parallel() before the next test starts, and that test blocks unless it also calls t.Parallel(). In other words, using the same /tmp/deviceplugin between all test functions should have been okay. I suspect it goes wrong sometimes because one test function starts a goroutine, does not wait for its completion, and that goroutine then interferes with the next test function when using the same dir, depending on timing. Running other test binaries in parallel and thus increasing system load probably also matters, together with overall number of CPUs. I think merging PR makes sense because a dynamic test directory is more flexible and enables running the tests in parallel (which could be a separate PR or be done as part of PR ), but I also think that it would be good if someone with a better understanding of the code that gets tested here could look into this race condition. [(quite) a bit later...] I chased down the spurious unlinkat() to UnixStream.Close for the socket, which unlinks the socket path [1].

By wrapping the listen socket such that a custom Close logs the call and a stack trace, I now have the smoking gun. [1] With some extra logging one can see that the that was created for TestNewManagerImplStart gets closed and unlinked while TestDevicePluginReRegistration already runs. The goroutine which runs too long is the from was called, but didn't wait for the goroutine to actually stop: That now begs the question: what is the right way to stop a grpc server? Below is the change I made to to track when it closes the socket:
On Tue, 2018-02-13 at 15:57 +0100, Patrick Ohly wrote: Server.Stop is the right way, it just doesn't fully stop the server. I consider this an issue in gRPC, therefore I have created https://github .com/grpc/grpc-go/issues/1861
Is it possible that defer statements are executed at the same time another test might start? EDIT: NVM looks like that's not the case
On Tue, 2018-02-13 at 07:39 -0800, Renaud Gaubert wrote: No, defer statements are guaranteed to run before a function returns. I think they can even change the return code and/or catch a panic.
thanks so much for your detailed debugging analysis and details about the tools you used (e.g. using filtered strace). I'm fairly new to golang and I've been messing around with the k8s source locally trying to get a feel for the project and work towards contributing, and I was debugging this test on my own but flailing against how to instrument the running tests. very much appreciated and nice work!


Question: flags.StringVar(&TestContext.ProgressReportURL, "progress-report-url", "", "The URL to POST progress updates to as the suite runs to assist in aiding integrations. If empty, no messages sent.") flags.StringVar(&TestContext.SpecSummaryOutput, "spec-dump", "", "The file to dump all ginkgo.SpecSummary to after tests run. If empty, no objects are saved/printed.") <ins> flags.StringVar(&TestContext.DockerConfigFile, "docker-config-file", "", "A file that contains credentials which can be used to pull images from certain private registries, needed for a test.") </ins> } // RegisterClusterFlags registers flags specific to the cluster e2e test suite.

"[] 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: import ( "fmt" "path" <del> "time" </del> "github.com/onsi/ginkgo" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [sig-storage] EmptyDir volumes [It] pod should support shared volumes between containers [Conformance] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
please don't CC sig-testing on every test failure :( we own the infrastructure etc. the sig-storage owns these tests.


Question: "A kubelet process is already running, don't know what to do" } Log-Output "Creating kubelet service" <del> & sc.exe create kubelet binPath= "${env:NODE_DIR}kubelet.exe ${kubelet_args}" start= demand </del> <ins> & sc.exe create kubelet binPath= "${env:NODE_DIR}kube-log-runner.exe -log-file=${env:LOGS_DIR}kubelet.log ${env:NODE_DIR}kubelet.exe ${kubelet_args}" start= demand </ins> & sc.exe failure kubelet reset= 0 actions= restart/10000 Log-Output "Starting kubelet service" & sc.exe start kubelet

/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for windows [ ] [ ] /sig windows /wg structured-logging
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I've started looking into this. Part of the problem is that go-runner is not part of kubernetes-node-windows- I suspect that is where the scripts get and kube- from.


Question: for _, name := range []string{"insecure-bind-address", "address"} { fs.IPVar(&bindAddr, name, bindAddr, ""+ <del> "The IP address on which to serve the insecure port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).") </del> <ins> "The IP address on which to serve the insecure port (set to 0.0.0.0 or :: for listening in all interfaces and IP families).") </ins> fs.MarkDeprecated(name, "This flag has no effect now and will be removed in v1.24.") }

<!-- 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: There are flag descriptions where is stated that the unspecified address behaves differently depending on the IP family: However, that's not the behavior implemented in and , clarified in the golang documentation What you expected to happen: Fix the comment to state the reality, i.e How to reproduce it (as minimally and precisely as possible): From the root of the kubernetes repo Anything else we need to know?: xref 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:
/kind cleanup /help wanted /good-first-issue /priority important-longterm /cc
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.
/assign /remove-help
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
For the flag in kube-proxy, is used if the address is not specified and can't be resolved by hostname, so I suggest to remove this comment: 0.0.0.0::` for all IPv6 interfaces'
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/remove-triage unresolved
I am very much in favor of this. Being correct and precise in these flags is valuable. To convince myself you were right, I wrote this program: And then I ran it for various inputs: In these flags and docs, we should be clear that if you are specifying a v6 addr and port you have to use syntax. Or maybe we should just audit and fix ALL such places to support and document that "nothing" is how you specify all interfaces. E.g. --bind-address=":80" is more obvious than either "0.0.0.0:80" or "[::]:80".

Even if those syntaxes work, let's just make "" the norm?
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 /lifecycle frozen
/help
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 : /help 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: var ValidateServiceAccountName = NameIsDNSSubdomain // maskTrailingDash replaces the final character of a string with a subdomain safe <del> // value if is a dash. </del> <ins> // value if it is a dash and if the length of this string is greater than 1. Note that // this is used when a value could be appended to the string, see ValidateNameFunc // for more info. </ins> func maskTrailingDash(name string) string { <del> if strings.HasSuffix(name, "-") { </del> <ins> if len(name) > 1 && strings.HasSuffix(name, "-") { </ins> return name[:len(name)-2] + "a" } return name

<!-- 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 --My controller had a bug where it was setting , and the client I was using () returned an internal server error when I tried to create it. In the API server logs, there was a panic at this line: apimachinery validation logic should handle this case gracefully, and the API server should return a helpful error to the client. Create a resource with the GenerateName field set to "-". This happened on Kind running locally & AKS, both v1.20.2 Kubernetes version (use ): v1.20.2 Cloud provider or hardware configuration: Kind/laptop, AKS OS (e.g: ): Darwin/LinuxKit (i.e. docker for macOS), AKS Install tools: Kind
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apimachinery 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 api-machinery
/assign
/assign /triage accepted


Question: configs[BusyBox] = Config{list.PromoterE2eRegistry, "busybox", "1.36.1-1"} configs[CudaVectorAdd] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "2.3"} <del> configs[DistrolessIptables] = Config{list.BuildImageRegistry, "distroless-iptables", "v0.6.1"} </del> <ins> configs[DistrolessIptables] = Config{list.BuildImageRegistry, "distroless-iptables", "v0.5.6"} </ins> configs[Etcd] = Config{list.GcEtcdRegistry, "etcd", "3.5.15-0"} configs[Httpd] = Config{list.PromoterE2eRegistry, "httpd", "2.4.38-4"} configs[HttpdNew] = Config{list.PromoterE2eRegistry, "httpd", "2.4.39-4"}

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: expectedClientActions:  2, maxEndpointsPerSubset:  2, expectedMetrics:        &expectedMetrics{desiredSlices: 2, actualSlices: 2, desiredEndpoints: 4, addedPerSync: 4, updatedPerSync: 0, removedPerSync: 0, skippedPerSync: 1, numCreated: 2, numUpdated: 0}, <ins> }, { testName: "The last-applied-configuration annotation should not get mirrored to created or updated endpoint slices", epAnnotations: map[string]string{ corev1.LastAppliedConfigAnnotation: "{"apiVersion":"v1","kind":"Endpoints","subsets":[]}", }, subsets: []corev1.EndpointSubset{{ Ports: []corev1.EndpointPort{{ Name:     "http", Port:     80, Protocol: corev1.ProtocolTCP, }}, Addresses: []corev1.EndpointAddress{{ IP:       "10.0.0.1", Hostname: "pod-1", }}, }}, existingEndpointSlices: []*discovery.EndpointSlice{}, expectedNumSlices:      1, expectedClientActions:  1, expectedMetrics:        &expectedMetrics{addedPerSync: 1, numCreated: 1, desiredEndpoints: 1, desiredSlices: 1, actualSlices: 1}, }, { testName: "The last-applied-configuration annotation shouldn't get added to created endpoint slices", subsets: []corev1.EndpointSubset{{ Ports: []corev1.EndpointPort{{ Name:     "http", Port:     80, Protocol: corev1.ProtocolTCP, }}, Addresses: []corev1.EndpointAddress{{ IP:       "10.0.0.1", Hostname: "pod-1", }}, }}, existingEndpointSlices: []*discovery.EndpointSlice{}, expectedNumSlices:      1, expectedClientActions:  1, expectedMetrics:        &expectedMetrics{addedPerSync: 1, numCreated: 1, desiredEndpoints: 1, desiredSlices: 1, actualSlices: 1}, }, { testName: "The last-applied-configuration shouldn't get mirrored to endpoint slices when it's value is empty", epAnnotations: map[string]string{ corev1.LastAppliedConfigAnnotation: "", }, subsets: []corev1.EndpointSubset{{ Ports: []corev1.EndpointPort{{ Name:     "http", Port:     80, Protocol: corev1.ProtocolTCP, }}, Addresses: []corev1.EndpointAddress{{ IP:       "10.0.0.1", Hostname: "pod-1", }}, }}, existingEndpointSlices: []*discovery.EndpointSlice{}, expectedNumSlices:      1, expectedClientActions:  1, expectedMetrics:        &expectedMetrics{addedPerSync: 1, numCreated: 1, desiredEndpoints: 1, desiredSlices: 1, actualSlices: 1}, }, { testName: "Annotations other than last-applied-configuration should get correctly mirrored", epAnnotations: map[string]string{ corev1.LastAppliedConfigAnnotation: "{"apiVersion":"v1","kind":"Endpoints","subsets":[]}", "foo":                              "bar", }, subsets: []corev1.EndpointSubset{{ Ports: []corev1.EndpointPort{{ Name:     "http", Port:     80, Protocol: corev1.ProtocolTCP, }}, Addresses: []corev1.EndpointAddress{{ IP:       "10.0.0.1", Hostname: "pod-1", }}, }}, existingEndpointSlices: []*discovery.EndpointSlice{}, expectedNumSlices:      1, expectedClientActions:  1, expectedMetrics:        &expectedMetrics{addedPerSync: 1, numCreated: 1, desiredEndpoints: 1, desiredSlices: 1, actualSlices: 1}, }, { testName: "Annotation mirroring should remove the last-applied-configuration annotation from existing endpoint slices", subsets: []corev1.EndpointSubset{{ Ports: []corev1.EndpointPort{{ Name:     "http", Port:     80, Protocol: corev1.ProtocolTCP, }}, Addresses: []corev1.EndpointAddress{{ IP:       "10.0.0.1", Hostname: "pod-1", }}, }}, existingEndpointSlices: []*discovery.EndpointSlice{{ ObjectMeta: metav1.ObjectMeta{ Name: "test-ep-1", Annotations: map[string]string{ corev1.LastAppliedConfigAnnotation: "{"apiVersion":"v1","kind":"Endpoints","subsets":[]}", }, }, AddressType: discovery.AddressTypeIPv4, Ports: []discovery.EndpointPort{{ Name:     utilpointer.StringPtr("http"), Port:     utilpointer.Int32Ptr(80), Protocol: &protoTCP, }}, Endpoints: []discovery.Endpoint{{ Addresses:  []string{"10.0.0.1"}, Hostname:   utilpointer.StringPtr("pod-1"), Conditions: discovery.EndpointConditions{Ready: utilpointer.BoolPtr(true)}, }}, }}, expectedNumSlices:     1, expectedClientActions: 1, </ins> }} for _, tc := range testCases {

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: apiVersion: apps/v1beta1 kind: Deployment metadata: <del> name: event-exporter-v0.1.0 </del> <ins> name: event-exporter-v0.1.4 </ins> namespace: kube-system labels: k8s-app: event-exporter

Every time watch is reset, event exporter exports an entry about it to Stackdriver. To make it less irritating, this has to be done once per container run Related image PR: /cc


Question: Ready            bool } <del> var _ = Describe("Container runtime Conformance Test", func() { </del> <ins> var _ = Describe("[FLAKY] Container runtime Conformance Test", func() { </ins> var cl *client.Client BeforeEach(func() {

As of now node e2e requires all the tests to pass. There are tests like the container conformance tests which have been flaky in the past - , , We need ability to mark certain tests as flaky and not run them as part of merge queue.
Ginkgo flags makes it possible to skip tests. We can use a prefix to not run flaky tests in our existing jenkins CIs.
Closing via


Question: sandbox5        = makeFakePodSandbox("sandbox1-name", "sandbox5-uid", "sandbox1-ns", true) container7      = makeFakeContainer(sandbox5, cName7, 0, true) containerStats7 = makeFakeContainerStats(container7, imageFsMountpoint) <ins> // A pod that cadvisor returns no stats sandbox6        = makeFakePodSandbox("sandbox6-name", "sandbox6-uid", "sandbox6-ns", false) container9      = makeFakeContainer(sandbox6, cName9, 0, false) containerStats9 = makeFakeContainerStats(container9, imageFsMountpoint) </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: CPU.Time is set to cs.StartTime but ps.Memory.Time is set to timestamp when collecting the memoryusage. What you expected to happen: CPU.Time is set to cs.CPU.Time How to reproduce it (as minimally and precisely as possible): Check the code Anything else we need to know?: Environment: Kubernetes version (use ): master branch when creating this issue. 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:
/assign
/sig kubelet
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubelet 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 node
I am happy to take over this. /assign