Question: t.Errorf("Did not expect an error %v", err) } <ins> // verify create/update/delete of object in non-existant namespace throws error err = handler.Admit(admission.NewAttributesRecord(&badPod, "Pod", badPod.Namespace, badPod.Name, "pods", "", admission.Create, nil)) if err == nil { t.Errorf("Expected an aerror that objects cannot be created in non-existant namespaces", err) } err = handler.Admit(admission.NewAttributesRecord(&badPod, "Pod", badPod.Namespace, badPod.Name, "pods", "", admission.Update, nil)) if err == nil { t.Errorf("Expected an aerror that objects cannot be updated in non-existant namespaces", err) } err = handler.Admit(admission.NewAttributesRecord(&badPod, "Pod", badPod.Namespace, badPod.Name, "pods", "", admission.Delete, nil)) if err == nil { t.Errorf("Expected an aerror that objects cannot be deleted in non-existant namespaces", err) } </ins> }

We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example


Question: // ServicePort contains information on service's port. message ServicePort { // The name of this port within the service. This must be a DNS_LABEL. <del> // All ports within a ServiceSpec must have unique names. This maps to // the 'Name' field in EndpointPort objects. </del> <ins> // All ports within a ServiceSpec must have unique names. When considering // the endpoints for a Service, this must match the 'name' field in the // EndpointPort. </ins> // Optional if only one ServicePort is defined on this service. // +optional optional string name = 1;

<!-- 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: When running a cluster service and manually created endpoints, the port name set on the cluster definition acts as an implicit selector - suitable end-points do not get mapped to the cluster service. What you expected to happen: Port name shouldn't be an implicit selector. How to reproduce it (as minimally and precisely as possible): Using the following spec file "": kubectl create -f , then describe the service. Output shows the endpoint as being correctly mapped Now run kubectl delete -f the and uncomment the name: foobar Re-run the kubectl create -f command. Now, checking the service gives the output below (end point isn't mapped): Anything else we need to know?: Adding the name: foobar to the endpoint definition makes the end point to be mapped again into the cluster. I.e. there is an implicit matching of the end-point and cluster port definitions. This is either a bug or a very surprising and undocumented feature Environment: kubectl version Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-03-25T02:52:13Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-01-16T18:14:49Z", GoVersion:"go1.10.7", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): root cat /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" Kernel (e.g.


Question: // ServicePort contains information on service's port. message ServicePort { // The name of this port within the service. This must be a DNS_LABEL. <del> // All ports within a ServiceSpec must have unique names. This maps to // the 'Name' field in EndpointPort objects. </del> <ins> // All ports within a ServiceSpec must have unique names. When considering // the endpoints for a Service, this must match the 'name' field in the // EndpointPort. </ins> // Optional if only one ServicePort is defined on this service. // +optional optional string name = 1;

): uname -a Linux 4.15.0-51-generic -Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/remove-sig api-machinery /sig network The name mapping to the endpoints is intentional, but needs documentation
/triage unresolved
/assign
It may be under-documented, but it is not UNdocmented.
Also
working on a PR to fix doc


Question: "os" "os/exec" "path" <ins> "regexp" </ins> "strings" "time" v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

<!-- 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 --There was a regression in containerd that required a fix for gmsa working with UNC paths. See the fix at We should have a test that validates this functionality. See for set up and place to add this test. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig windows /triage accepted /priority important-long-term /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 : <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! --#### What happened: There was a regression in containerd that required a fix for gmsa working with UNC paths. See the fix at We should have a test that validates this functionality. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig windows /triage accepted /priority important-long-term /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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : There was a regression in containerd that required a fix for gmsa working with UNC paths. See the fix at We should have a test that validates this functionality. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g.


Question: "os" "os/exec" "path" <ins> "regexp" </ins> "strings" "time" v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig windows /triage accepted /priority important-long-term /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
/priority important-longterm
/assign
if you have questions feel free to reachout on slack in sig-windows
Will do, thanks!
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .


Question: "os" "os/exec" "path" <ins> "regexp" </ins> "strings" "time" v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

/lifecycle rotten [1]:
/remove-lifecycle rotten
/remove-lifecycle rotten
/assign
I have thought about this a bit and think it might be easiest to just expose a share on the domain controller. This does push more requirements into the configuration that needs to happen outside of the tests but it will make the tests a lot cleaner IMO.
/assign
GitHub didn't allow me to assign the following users: iXinqi. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: "spec: Forbidden: pod updates", "removed priority class name", }, <ins> { core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(1), }, }, core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(-1), }, }, "", "update termination grace period seconds", }, { core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(0), }, }, core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(-1), }, }, "spec: Forbidden: pod updates", "update termination grace period seconds not 1", }, </ins> } for _, test := range tests {

<!-- 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: Some k8s client tried to evict a pod by setting negative value for deletionGracePeriodSeconds. But all eventual delete calls (and force-delete calls) made by kubelet, pod-garbage-collector, etc were not able to delete that pod, because apiserver doesnt allow deletionGracePeriodSeconds to be increased once it is set. So force-delete (which set it to 0) doesn't take effect when it's already negative. Not even kubectl is able to call delete with negative grace-period. But curl with an even more negative grace-period value worked. What you expected to happen: force-delete works. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I think the issue is in the code below As the comment suggest, in phase 1, the was set to a negative value (meaning was in the past), and in phase 2, has to be set even lower, otherwise, it will be considered as pending graceful deletion and not performing the immediate delete. I think there're two possible fixes. not allowing setting in the past ( should be non-negative). In that case, we could convert to 0 if negative. that could be set in the past. In that case, in phase 2, we treat negative value of the same as 0, and allow immediate delete. Thoughts? Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig api-machinery Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/cc /triage accepted
No component in the system should ever treat the timestamp of DeletionTimestamp as authoritative.


Question: "spec: Forbidden: pod updates", "removed priority class name", }, <ins> { core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(1), }, }, core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(-1), }, }, "", "update termination grace period seconds", }, { core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(0), }, }, core.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "foo", }, Spec: core.PodSpec{ TerminationGracePeriodSeconds: utilpointer.Int64Ptr(-1), }, }, "spec: Forbidden: pod updates", "update termination grace period seconds not 1", }, </ins> } for _, test := range tests {

In Kube, components are required to calculate the time period from when they observe the event in their local clock (i.e. 30s from now), not use the deletion timestamp. A negative value of deletion grace period should be rejected by the apiserver as an invalid value (bad request / invalid field).
attempts to take a missing or positive deletion grace period negative should be rejected, I agree. if a negative value is already persisted, I'd be inclined to allow a negative value in an update and clip to 0
As I mentioned in the PR, eviction is passing negatives through to the store: In kubectl, we specify the default value for GracePeriod is -1. In the case of delete, we simply don't set the value in the deleteOptions we send to the API. In the case of eviction, we send the -1 value, and that gets passed along to the store.
I don't see the -1 getting sent to the eviction API. It looks like values < 0 result in a nil value being sent to the API: I would not expect the API to accept a negative value as-is.
Looks like you are correct. Do the deletionOptions go through their own validation or through some kind of validation for the evict API? The original bug report mentions 'evict' though it's not clear if the eviction API was used or not.
ValidateDeleteOptions is called inside pod deletion, but did not check that the field was non-negative. I don't see any eviction-specific validation.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle rotten
Im investigating the and . Surprisingly see you here...


Question: interference, deadlines, and so on. Workload-specific requirements will be exposed through the API as necessary.`, Run: func(cmd *cobra.Command, args []string) { <del> verflag.PrintAndExitIfRequested() utilflag.PrintFlags(cmd.Flags()) if len(args) != 0 { fmt.Fprint(os.Stderr, "arguments are not supportedn") } if errs := opts.Validate(); len(errs) > 0 { fmt.Fprintf(os.Stderr, "%vn", utilerrors.NewAggregate(errs)) os.Exit(1) } if len(opts.WriteConfigTo) > 0 { if err := options.WriteConfigFile(opts.WriteConfigTo, &opts.ComponentConfig); err != nil { fmt.Fprintf(os.Stderr, "%vn", err) os.Exit(1) } glog.Infof("Wrote configuration to: %sn", opts.WriteConfigTo) return } c, err := opts.Config() if err != nil { fmt.Fprintf(os.Stderr, "%vn", err) os.Exit(1) } stopCh := make(chan struct{}) if err := Run(c.Complete(), stopCh); err != nil { </del> <ins> if err := run(cmd, args, opts); err != nil { </ins> fmt.Fprintf(os.Stderr, "%vn", err) os.Exit(1) }

PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: In the function creates a object and populates the field with an anonymous function. At the end of that function, is called, which contains the rest of our startup logic. Rather than split this across two functions, we should put all the startup logic in one named function called (not ) so that constructing the object is much more plain. /sig scheduling /kind cleanup /help /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 : PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: Rather than split this across two functions, we should put all the startup logic in one named function called (not ) so that constructing the object is much more plain. /kind cleanup /help /good-first-issue </details
I'll pick this up! /assign


Question: return nil } <ins> func (f *fakePodWorkers) IsPodKnownTerminated(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock() return f.terminated[uid] } </ins> func (f *fakePodWorkers) CouldHaveRunningContainers(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()

There appears to be a change of behavior / possible regression in k8s 1.22 with respect to pod lifecycle behavior. We've started to see some cases when multiple pods are being created (often as part of a k8s job) the following will happen: pods get created by e.g. job controller (e.g. say 5). Each pod in job requests majority of node memory so only one such pod can fit on node at a time. schedules [first] pod to node, rest (4 pods) stay in pending accepts first pod, runs it to completion pod get scheduled to the node rejects the pod during pod admission, e.g. with , despite the fact that the first pod has already completed successfully This results in many of pods backing the job getting into Failed phase and having to be recreated by job controller. The job can often get into BackofLimit exceeded to hitting backoffLimit. The root issue seems to be a mismatch of when kubelet actually considers the pod to complete and what it reports to API server (which causes the followup pods to be scheduled to it). I'm still investigating further, but this may be related to the pod lifecycle changes in 1.22 -- I've created a e2e test as minimal repro of this behavior -- (Test fails) 22 build log -- 22 kubelet log -- (Test passes) 21 build log -- 21 kubelet log -- <!-- 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 --- 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:
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.


Question: return nil } <ins> func (f *fakePodWorkers) IsPodKnownTerminated(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock() return f.terminated[uid] } </ins> func (f *fakePodWorkers) CouldHaveRunningContainers(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()

</details
/sig node
/cc
Looking at the kubelet log in 1.22 () here's what I see -- First pod starts up... starts dies after ~10 seconds since the job is completed (the container simply runs a ) Pod completes, status is updated to API server Next pod comes in but is rejected with despite the earlier pod already being completed/terminated
did the kubelet pod lifecycle rework result in a reordering of kubelet resource bookeeping w.r.t. pod status? it seems reasonable for the scheduler to send another pod to a kubelet once it reports the pod complete and the use of the resources is done from an API perspective
I am also seeing this same behavior, but with "OutOfPods" rather than "OutOfMemory", when running a job with parallelism=100, completions=400 on GKE (which has a 110 pod per node limit).
this is easily reproducible on a local cluster as well start with this: then create this job: result on 1.22 is the job hangs with 2 completions and a bunch of rejections by the kubelet: on 1.21, the same job completes all pods successfully in a couple minutes with no OutOfpods errors
verified introduced the OutOfPods issue
Shame we didn’t have an e2e which caught this given how easy the reproducer is. This looks to be the opposite of the previous cpu admission bug (ignoring things that are terminating but not terminated). We are weak on admission testing in general. This potentially implies admission is looking at the wrong set of pods (admitted + terminating). Note there is already a bug in 1.21 and before where force deleted pods are incorrectly ignored from the set of allocated resources while they are terminating, but this doesn’t immediately seem to be that issue (since i doubt those jobs are being force deleted)
yeah, there was no force deletion involved in (or any deletion at all, actually... the completed pods just sat there, completed)
The set of admitted pods considered for pod count is everything in the pod manager filtered by filterOutTerminatingPods, which calls CouldHaveRunningContainers which returns true once a pod is seen by the workers (shortly after admission, and until we’ve confirmed via syncTerminatingPod that no containers are running). Whatever the problem is it’s likely in the interaction of that.


Question: return nil } <ins> func (f *fakePodWorkers) IsPodKnownTerminated(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock() return f.terminated[uid] } </ins> func (f *fakePodWorkers) CouldHaveRunningContainers(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()

A pod the pod worker hasn’t seen yet is also filtered out (that means bursts of pods can get in, which seems the opposite of this problem, and is the bug i mentioned before).
Edit: one wrong thing spotted while looking - I'm not sure it fixes the issue you're seeing, but it's definitely wrong for admission (admission is filtering the known pod set down to remove pods that are terminated, but shouldn't filter pods that aren't admitted yet). This needs a node e2e reproducer that can run in serial (resource consumption is really hard to test from parallel, is slow in serial, and node e2e is back in a good state now) - / is that something either of you could help me with? I believe the reason the existing tests don't catch this is the job controller is creating pods fast enough that we see races in admission (multiple pods are admitted in one call to HandlePodAdditions) that are not caught in the current serial node e2e admission tests which rarely create more than one at a time.
Job pods still go through the scheduler to get assigned to a node, so even though the job controller can create pods in parallel, I'd still expect them to arrive at the node in an orderly fashion. It's still possible multiple arrive in a single HandlePodAdditions call, of course. It seems like kubelet admission is using laggy information that doesn't reflect pod completion the kubelet itself wrote to the pod API.
The bug turned out to be much simpler. Pods that are completed never go to the pod worker, so once a pod has reached terminal state it was being back to the list of active pods. The set of e2es that would have prevented this regression: node e2e that creates multiple pods at the same time and verifies that admission works correctly when HandlePodAdditions takes two pods at once node e2e that verifies that completed pods don't consume resources for admission purposes in the kubelet job controller e2e that attempts to verify some part of this reliably (ideally in a way that can be run in parallel e2e)
another related issue:
Linking here for completeness - a similar symptom might get exposed after this fix as described in The kubelet considers resources for terminating pods to be in use (they are!), but the scheduler ignores terminating pods and schedules new pods.


Question: return nil } <ins> func (f *fakePodWorkers) IsPodKnownTerminated(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock() return f.terminated[uid] } </ins> func (f *fakePodWorkers) CouldHaveRunningContainers(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()

Because the kubelet now considers terminating pods, it rejects those rapidly rescheduled pods. The follow up is more involved but requires the kubelet to allow pods to be potentially admitted that can't be run currently due to those terminating pods. See the linked issue.


Question: return cmd } <del> // Run runs the Scheduler. func Run(c schedulerserverconfig.CompletedConfig, stopCh <-chan struct{}) error { </del> <ins> // run runs the scheduler. func run(cmd *cobra.Command, args []string, opts *options.Options) error { verflag.PrintAndExitIfRequested() utilflag.PrintFlags(cmd.Flags()) if len(args) != 0 { fmt.Fprint(os.Stderr, "arguments are not supportedn") } if errs := opts.Validate(); len(errs) > 0 { fmt.Fprintf(os.Stderr, "%vn", utilerrors.NewAggregate(errs)) os.Exit(1) } if len(opts.WriteConfigTo) > 0 { if err := options.WriteConfigFile(opts.WriteConfigTo, &opts.ComponentConfig); err != nil { fmt.Fprintf(os.Stderr, "%vn", err) os.Exit(1) } glog.Infof("Wrote configuration to: %sn", opts.WriteConfigTo) } c, err := opts.Config() if err != nil { fmt.Fprintf(os.Stderr, "%vn", err) os.Exit(1) } stopCh := make(chan struct{}) // Get the completed config cc := c.Complete() </ins> // To help debugging, immediately log version glog.Infof("Version: %+v", version.Get())


Question: for format := range jsonFormats { formats = append(formats, format) } <ins> sort.Strings(formats) </ins> return formats }

/kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related 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


Question: outputOpts, _ = outputOptsForMappingFromOpenAPI(f, mapping) } <del> printer, err = f.PrinterForMapping(cmd, false, outputOpts, mapping, allNamespaces) </del> <ins> printer, err = f.PrinterForMapping(cmd, false, outputOpts, mapping, printWithNamespace) </ins> if err != nil { if !errs.Has(err.Error()) { errs.Insert(err.Error())

This is wrong, cluster scoped resources should never have a NAMESPACE column. We need to fix and add a test to ensure this doesn't regress.
The presence of the flag is what triggers this.
I would help fix it.
I mean to add a test after modification, but found that current test framework could not support the case: To cover the scene, we need a real NewHumanReadablePrinter in test case, to ensure the output format, and modify the related funcs in FakeFactory to support pass in param withNamespace. I feel this not like behavior of unit test to some extent. The loss may outweighs the gain to have such a big impact on the whole. What's your opinion
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: set -o pipefail KUBE_ROOT=${KUBE_ROOT:-$(dirname "${BASH_SOURCE}")/..} <del> source "${KUBE_ROOT}/cluster/kube-util.sh" </del> source "${KUBE_ROOT}/cluster/clientbin.sh" # If KUBEADM_PATH isn't set, gather up the list of likely places and use ls

https://k8s- example run from https://k8s- which just edits a md file.
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
timeout is 120s, set 360s can fix this in my local env, not sure what happened.
tracked it down to introduced in
can you take a look at
i tried the posted by a few times and noticed variations of time taken, then removed the last few commits and ran them again and saw they were stable. then all the commits back until they failed which was the last commit. Then i looked inside and noticed the random which has caused pain before (in openstack). Ack looking


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected socket file, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected socket file, got unexpected file: %s", i, tc.name, path) } if oftc.IsBlock() {

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: This feature is lacking coverage, especially for containerized kubelet environments.
/assign since I'm the owner of this feature.
And just fixes a bug for containerized kubelet when the mount file is an empty file.
Are we going to enable these tests in v1.11? We're getting code freeze soon.
There is a local containerized cluster pull and CI job that we can probably leverage. Right now it only runs conformance tests, we may be able to add new suites to enable other tests. Cc who can point us to the owner for the containerized testing effort
yes, seems to be holding up pretty well - https://k8s-,%20master%20(dev)
In I made pull-kubernetes-local-e2e-containerized to run also all test with string. I'm enabling some tests (subpath!) in , feel free to suggest more tests.
Ref
IIUC, the default host path type is . And when host path type is , we expect container runtime to create the host path if it doesn't exist (docker is doing that today). Is that true? If that is, we should revert part of , because container runtime should still create host path if it does not exist. /cc I tried to enforce , and got a lot of errors , e.g.:
Correct. This is mainly for backwards compatibility.
I see. If so, I'll remove the CRI definition "If the hostPath doesn't exist (e.g. hostPath volume), runtimes should report errors". Thanks!
SGTM. Refer to .
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 will help fix this.
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.


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected socket file, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected socket file, got unexpected file: %s", i, tc.name, path) } if oftc.IsBlock() {

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
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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
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
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with .


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected socket file, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected socket file, got unexpected file: %s", i, tc.name, path) } if oftc.IsBlock() {

Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: cmd.AddCommand(NewCmdCreatePodDisruptionBudget(f, ioStreams)) cmd.AddCommand(NewCmdCreatePriorityClass(f, ioStreams)) cmd.AddCommand(NewCmdCreateJob(f, ioStreams)) <ins> cmd.AddCommand(NewCmdCreateCronJob(f, ioStreams)) </ins> return cmd }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Why is this needed: Because of is not recommended to create cronjob (with flags) anymore. But there is no imperative command available for to create cronjob. /sig CLI <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
GitHub didn't allow me to assign the following users: Pingan2017. Note that only and repo collaborators can be assigned. 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
i wanna work on this. give me several days
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


Question: // TODO: provide exact specification for format. Source string `json:"source,omitempty" description:"component reporting this event; short machine understandable string"` // Host name on which the event is generated. <del> Host string `json:"host,omitempty"` </del> <ins> Host string `json:"host,omitempty" description:"host name on which this event was generated"` </ins> // The time at which the client recorded the event. (Time of server receipt is in TypeMeta.) Timestamp util.Time `json:"timestamp,omitempty" description:"time at which the client recorded the event"`

Or for some other reason it complains about v1beta1 and 2 on my system even though actually grepping those files shows no problems.
it's griping about Host


Question: } return true, err } else if err != nil { <del> // TODO(#109732): stop polling and return the error in this case. </del> e2elog.Logf("Error evaluating pod condition %s: %v", conditionDesc, err) <ins> if IsFinal(err) { return false, err } </ins> } return false, nil })

treats any error returned by the condition as terminal, but silently ignores any errors that aren't returned along with . We should change WaitForPodCondition to behave like . /sig testing /area e2e-test-framework
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
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
Was there any reason why you instead of doing this right away? I fully agree with this issue, we should abort early. I just found the TODO because I have a failing test that ran longer than expected after a final pod failure and that made me check out why it didn't abort quicker :grin:


Question: return client.Do(req) } <ins> func TestInstallThirdPartyAPIListOptions(t *testing.T) { for _, version := range versionsToTest { testInstallThirdPartyAPIListOptionsForVersion(t, version) } } func testInstallThirdPartyAPIListOptionsForVersion(t *testing.T, version string) { _, etcdserver, server, assert := initThirdParty(t, version) // TODO: Uncomment when fix #19254 // defer server.Close() defer etcdserver.Terminate(t) // send a GET request with query parameter resp, err := httpGetWithRV(server.URL + "/apis/company.com/" + version + "/namespaces/default/foos") if !assert.NoError(err) { t.Fatalf("unexpected error: %v", err) } assert.Equal(http.StatusOK, resp.StatusCode) } func httpGetWithRV(url string) (*http.Response, error) { req, err := http.NewRequest("GET", url, nil) if err != nil { return nil, err } q := req.URL.Query() // resourceversion is part of a ListOptions q.Add("resourceversion", "0") req.URL.RawQuery = q.Encode() client := &http.Client{} return client.Do(req) } </ins> func TestInstallThirdPartyResourceRemove(t *testing.T) { for _, version := range versionsToTest { testInstallThirdPartyResourceRemove(t, version)

A user report that it's broken in the slack channel:
Also and -- this probably broke with one of our recent refactors. The server should be accepting list options from any version, I thought?
FWIW, I think it's this line barf at the ListOptions: The parameter codec first decodes the query parameter to a versioned object and then convert it to the internal object. The code fails because it cannot create a "" ListOptions.
The server should accept list options in the API version it is sent. ListOptions should be registered in all third party groups.
The thirdPartyResourceDataCreator should handle "ListOptions", which surprises me that it doesn't then respect the group.
I think we should add a wrapper around the api.ParameterCodec here: Do something similar as what does.
Putting together a PR now and will let you guys review.
I guess my point is, the list options are just there from the URL query parameters. The user didn't send a group. Why do we assume that value for the group rather than "/v1" or something?
My understanding is we want to allow options to evolve differently in different groups. We do have v1.ListOptions and v1beta1.ListOptions. And if a client sends requeset to extensions/v1beta1 endpoint, then it's expected to encode the ListOptions to v1beta1 and then convert it to query parameters.
Mostly because the parameter codec is supposed to abstract that. "virtual" groups need to be implemented by the virtual "parameter codec". The statement on floating server objects (List, Delete etc) was that they have a locked API schema, and we have a mechanism to do that via the scheme which is registering them in a group. , Daniel Smith wrote:


Question: } clock := clock.NewFakeClock(time.Now()) <del> watchers := newTimeBucketWatchers(clock) </del> <ins> watchers := newTimeBucketWatchers(clock, defaultBookmarkFrequency) </ins> now := clock.Now() watchers.addWatcher(newWatcher(now.Add(10 * time.Second))) watchers.addWatcher(newWatcher(now.Add(20 * time.Second)))

Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.


Question: "Default watch cache size. If zero, watch cache will be disabled for resources that do not have a default watch size set.") fs.StringSliceVar(&s.WatchCacheSizes, "watch-cache-sizes", s.WatchCacheSizes, ""+ <del> "List of watch cache sizes for every resource (pods, nodes, etc.), comma separated. "+ "The individual override format: resource[.group]#size, where resource is lowercase plural (no version), "+ "group is optional, and size is a number. It takes effect when watch-cache is enabled. "+ </del> <ins> "Watch cache size settings for some resources (pods, nodes, etc.), comma separated. "+ "The individual setting format: resource[.group]#size, where resource is lowercase plural (no version), "+ "group is omitted for resources of apiVersion v1 (the legacy core API) and included for others, "+ "and size is a number. It takes effect when watch-cache is enabled. "+ </ins> "Some resources (replicationcontrollers, endpoints, nodes, pods, services, apiservices.apiregistration.k8s.io) "+ "have system defaults set by heuristics, others default to default-watch-cache-size")

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I wanted to set the watch cache size for some Kinds, and realized I was unsure of the syntax. After investigation and prompting, the flag help was updated to describe the syntax. But the description has an error. The flag help () says the group is optional. But the code makes it clear that the group is NOT optional. See how invokes schema.ParseGroupResource, which does not do any normalization --- the group appears in the result if and only if the user supplied the group in the string on the command line. See how and index the map by the canonical and only that. So if the user supplies the group and the canonical elides the group, or if the user elided the group and the canonical includes the group, the user's entry in the map will not be found. What you expected to happen: I expected the command line flag help to be accurate. How to reproduce it (as minimally and precisely as possible): I think the code inspection is easier than a demo in this case. If you want a demo, run an apiserver with and look at the debug messages about the watch cache sizes used for pods and jobs. Anything else we need to know?: no Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/cc
lgtm'ed on the pr
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen


Question: pod.Annotations[podcmd.DefaultContainerAnnotationName] = name return pod } <ins> func TestReattachMessage(t *testing.T) { tests := []struct { name          string pod           *corev1.Pod rawTTY, stdin bool container     string expected      string }{ { name:      "normal interactive session", pod:       attachPod(), container: "bar", rawTTY:    true, stdin:     true, expected:  "Session ended, resume using", }, { name:      "no stdin", pod:       attachPod(), container: "bar", rawTTY:    true, stdin:     false, expected:  "", }, { name:      "not connected to a real TTY", pod:       attachPod(), container: "bar", rawTTY:    false, stdin:     true, expected:  "", }, { name: "no restarts", pod: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "test"}, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyNever, Containers:    []corev1.Container{{Name: "bar"}}, }, Status: corev1.PodStatus{Phase: corev1.PodRunning}, }, container: "bar", rawTTY:    true, stdin:     true, expected:  "", }, { name:      "ephemeral container", pod:       attachPod(), container: "debugger", rawTTY:    true, stdin:     true, expected:  "Session ended, the ephemeral container will not be restarted", }, } for _, test := range tests { t.Run(test.name, func(t *testing.T) { options := &AttachOptions{ StreamOptions: exec.StreamOptions{ Stdin: test.stdin, }, Pod: test.pod, } if msg := options.reattachMessage(test.container, test.rawTTY); test.expected == "" && msg != "" { t.Errorf("reattachMessage(%v, %v) = %q, want empty string", test.container, test.rawTTY, msg) } else if !strings.Contains(msg, test.expected) { t.Errorf("reattachMessage(%v, %v) = %q, want string containing %q", test.container, test.rawTTY, msg, test.expected) } }) } } </ins>

When attaching to an ephemeral container, prints a message suggesting that the container can be reattached after it exists. This is not true because an ephemeral container is never restarted. This cosmetic issue should be resolved for
/assign /sig node /triage accepted /priority important-longterm


Question: }) Describe("container runtime conformance blackbox test", func() { <del> var testCContainers []ConformanceContainer </del> namespace := "runtime-conformance" <del> BeforeEach(func() { testCContainers = []ConformanceContainer{} }) Context("when start a container that exits successfully", func() { </del> <ins> Context("when starting a container that exits", func() { </ins> It("it should run with the expected status [Conformance]", func() { <ins> restartCountVolumeName := "restart-count" restartCountVolumePath := "/restart-count" </ins> testContainer := api.Container{ Image: ImageRegistry[busyBoxImage], VolumeMounts: []api.VolumeMount{ { <del> MountPath: "/restart-count", Name:      "restart-count", </del> <ins> MountPath: restartCountVolumePath, Name:      restartCountVolumeName, </ins> }, }, <del> ImagePullPolicy: api.PullIfNotPresent, </del> } testVolumes := []api.Volume{ { <del> Name: "restart-count", </del> <ins> Name: restartCountVolumeName, </ins> VolumeSource: api.VolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: os.TempDir(),

Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc


Question: // test pods from running, and tests that ensure all pods are running and // ready will fail). if err := waitForPodsRunningReady(api.NamespaceDefault, testContext.MinStartupPods, podStartupTimeout); err != nil { <del> glog.Fatalf("Error waiting for all pods to be running and ready: %v", err) </del> <ins> t.Errorf("Error waiting for all pods to be running and ready: %v", err) return </ins> } // Run tests through the Ginkgo runner with output to console + JUnit for Jenkins var r []ginkgo.Reporter if *reportDir != "" { r = append(r, reporters.NewJUnitReporter(path.Join(*reportDir, fmt.Sprintf("junit_%02d.xml", config.GinkgoConfig.ParallelNode)))) <del> failReport := &failReporter{} r = append(r, failReport) defer func() { if failReport.failed { coreDump(*reportDir) } }() </del> } ginkgo.RunSpecsWithDefaultAndCustomReporters(t, "Kubernetes e2e suite", r) }

We for uploading to GCS on , but not on successful e2e runs or failed test -up. We should definitely be dumping those logs for failed cluster-ups, and it would also be nice to throw in the successes too (good to have recent green for comparison).
Getting logs uploaded on a failed test -up seems really important for debugging.
+1 There were just a bunch of failures in scalability test suite (run 1623-1628) that failed because not all system pods were running. Since there are no logs, there is no easy way to debug it. It would be super useful to have all the logs for failed cluster-ups. cc
Unless I'm confused, it looks as if these logs are still not being uploaded. FYI.
For example: gs://kubernetes-jenkins/logs/kubernetes-e2e-gce/7500
That particular build was a timeout. When Jenkins kills the job, the log-collecting code never runs.
Another case we won't collect logs is if the cluster fails to initialize. (Which is a really important place to collect logs, but it's not a trivial fix.)
Moving this into post, since it seems unlikely to get fixed in the near term. feel free to correct me if I'm wrong.
We also don't collect logs on test job timeouts, which is frustrating.
+1
will collect the logs when the cluster fails to initialize. That's not all the cases listed here, but it's a good one.
I'd like to bump the priority for this further - we don't have any logs to help with debugging , which started to happen more often recently - it seems that didn't help. cc
I have too many P0s assigned to me already. This is at least 3rd in line right now.
This one is half year old and is P0 for a month...
From discussion with on hangouts, a vague plan: move log-dumping logic from into a standalone command in something like (feel free to bikeshed the name) update Jenkins to call this command as a post-build step probably remove and the debug stuff recently to . Right now the stuff is pretty GCE/GKE specific and uses ssh. We should probably change to a more provider-agnostic method, but this would be a good start.
Hm, actually, post-build step actually won't work, since we tear down the cluster first.


Question: // test pods from running, and tests that ensure all pods are running and // ready will fail). if err := waitForPodsRunningReady(api.NamespaceDefault, testContext.MinStartupPods, podStartupTimeout); err != nil { <del> glog.Fatalf("Error waiting for all pods to be running and ready: %v", err) </del> <ins> t.Errorf("Error waiting for all pods to be running and ready: %v", err) return </ins> } // Run tests through the Ginkgo runner with output to console + JUnit for Jenkins var r []ginkgo.Reporter if *reportDir != "" { r = append(r, reporters.NewJUnitReporter(path.Join(*reportDir, fmt.Sprintf("junit_%02d.xml", config.GinkgoConfig.ParallelNode)))) <del> failReport := &failReporter{} r = append(r, failReport) defer func() { if failReport.failed { coreDump(*reportDir) } }() </del> } ginkgo.RunSpecsWithDefaultAndCustomReporters(t, "Kubernetes e2e suite", r) }

But making it a separate command can still let us call it in more places.
FYI - we also need logs from timed-out runs (not only the failed ones).
moving out into its own binary should help accomplish this.
I'm worried that the best way to do this is to write a bash script that grabs IPs from 's and functions and just does an ssh and cats the logs. Then we could point at that. It's sorta difficult to make work on its own.
I think at this point we're happy with anything that usually works. We can work on making in nice and shiny later.
We now get logs when kube-up fails, which recently happened :) Still some work to do here, I'll leave this issue open until timeouts are handled properly and points here.
- I can't thank you enough!
Ok, is in so we should get logs for kubernetes-e2e-* jobs and PR Jenkins jobs on timeout.
I'm gonna call this done.


Question: return "", err } <del> // If the volumeMode is 'Block', plugin don't have to format the volume. // The globalPDPath will be created by operationexecutor. Just return devicePath here. klog.V(5).Infof("fc: AttachDisk volumeMode: %s, devicePath: %s", b.volumeMode, devicePath) if b.volumeMode == v1.PersistentVolumeBlock { return devicePath, nil } // mount it globalPDPath := util.MakeGlobalPDName(*b.fcDisk) if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } noMnt, err := b.mounter.IsLikelyNotMountPoint(globalPDPath) if err != nil { return devicePath, fmt.Errorf("Heuristic determination of mount point failed:%v", err) } if !noMnt { klog.Infof("fc: %s already mounted", globalPDPath) return devicePath, nil } err = b.mounter.FormatAndMount(devicePath, globalPDPath, b.fsType, b.mountOptions) if err != nil { return devicePath, fmt.Errorf("fc: failed to mount fc volume %s [%s] to %s, error %v", devicePath, b.fsType, globalPDPath, err) } return devicePath, err </del> <ins> return devicePath, nil </ins> } // DetachDisk removes scsi device file such as /dev/sdX from the node.

What happened: An iSCSI PV with is mounted without these options. What you expected to happen: The volume is mounted with . Anything else we need to know?: iSCSI volume is mounted in and passes as : This can be fixed trivially, however, why is it mounted in at all? There is another mount attempt in , with correct mount options: This code is skipped, because the volume is already mounted. Environment: Kubernetes version (use ): today's master, v1.19.0-alpha.0.781+-dirty , do you remember why we mount stuff in ? iSCSI and FibreChannel does so, the others don't.
/sig storage


Question: err = wait.PollImmediate(dsRetryPeriod, dsRetryTimeout, checkRunningOnAllNodes(f, ds)) Expect(err).NotTo(HaveOccurred(), "error waiting for daemon pod to start") <del> By(fmt.Sprintf("Make sure all daemon pods have correct template generation %d", templateGeneration)) err = checkDaemonPodsTemplateGeneration(c, ns, label, fmt.Sprint(templateGeneration)) Expect(err).NotTo(HaveOccurred()) </del> // Check history and labels ds, err = c.AppsV1().DaemonSets(ns).Get(ds.Name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred())

Please see : https://k8s- fails just after this line: Failure was introduced in: But this was not noticed until it started running in [Conformance] tests. You can see the same problem in other dashboards too: https://k8s- https://k8s-
cc /sig apps
/priority critical-urgent
/kind bug /priority failing-test
/milestone v1.10
Is this just an oversight of not removing the template generation when the API update was done?
/cc
triaged in progress
i have never touched this test before ... so i just threw in a WIP, feel free to use/discard it. there seems to be lot of methods in there that is no longer used, may be we can rip those out too. (see )
xref
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action Required: This issue has not been updated since Mar 5. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"sh", "-c"}, Args: []string{` <ins> sleep 9999999 & PID=$! </ins> _term() { <ins> kill $PID </ins> echo "Caught SIGTERM signal!" <del> exit 0 </del> } trap _term SIGTERM <del> while true; do sleep 5; done </del> <ins> wait $PID exit 0 </ins> `, }, },

Followup feedback from In a few e2e node tests (e.g. tests of deletion grace period) we have some busybox pods that wait for SIGTERM and perform some action like a small sleep to simulate SIGTERM taking some time. These tests follow the pattern of -- see The will block the SIGTERM handler from being run until after the time is elapsed. We should consider to remove the and instead use to avoid blocking the SIGTERM handler, see pattern followed in n/a n/a No response n/a n/a <details</details<details</details<details</details<details</details
/sig node /cc
/assign
/triage accepted


Question: Description: The Pod with toleration timeout scheduled on a tainted Node MUST not be evicted if the taint is removed before toleration time ends. */ <del> framework.ConformanceIt("removing taint cancels eviction", func() { </del> <ins> framework.ConformanceIt("removing taint cancels eviction [Disruptive]", func() { </ins> podName := "taint-eviction-4" pod := createPodForTaintsTest(true, 2*additionalWaitPerDeleteSeconds, podName, podName, ns) observedDeletions := make(chan string, 100)

What would you like to be : Our tooling that makes the list of conformance tests needs to allow conformance tests to be marked as disruptive. Why is this needed: To test default, conformance behavior which may be disruptive (e.g. taint eviction) ref /sig testing /area conformance


Question: Description: The Pod with toleration timeout scheduled on a tainted Node MUST not be evicted if the taint is removed before toleration time ends. */ <del> framework.ConformanceIt("removing taint cancels eviction", func() { </del> <ins> framework.ConformanceIt("removing taint cancels eviction [Disruptive]", func() { </ins> podName := "taint-eviction-4" pod := createPodForTaintsTest(true, 2*additionalWaitPerDeleteSeconds, podName, podName, ns) observedDeletions := make(chan string, 100)

What happened: Ran a conformance test run (using Sonobuoy) on One of the taint based tests a NoExecute taint to a node which evicted all workloads including the Sonobuoy workload itself. If this had been a prod workload, numerous prod workloads could have been impacted. What you expected to happen: Test run as normal with reasonable results. Able to run conformance tests with minimal impact on a running cluster. How to reproduce it (as minimally and precisely as possible): on a v1.16.0 cluster. Anything else we need to know?: Environment: Kubernetes version (use ): /area conformance
/sig testing /sig architecture /sig scheduling
Summarizing the many conversations on the PR and in Slack regarding this: We wish we had identified the lack of a tag sooner and could have taken better action. Since the release is 2 days away and our own tooling currently prohibits us from marking tests as both and , we've decided to let the release proceed with this "bug". Risk: Someone running the conformance tests may unexpectedly have their workloads evicted Mitigation: Sonobuoy v0.16.0 will provide the capabilities to the user to run a "conformance-lite" (name TBD) run if they'd like to run the conformance tests against a cluster with prod workloads. This way end-users can still be reasonably sure of their cluster's continued well-being. This mode will manually skip the tests in question until they can be more appropriately marked as Sonobuoy will also provide, consistent with past behavior, the means to run the full conformance suite including these disruptive tests. Eventual solution: Sonobuoy will, most likely, need to continue offering a "non-disruptive-conformance" mode to aid in end user testing but the regexp will change and should be able to just skip tests K8s tooling needs to be tweaked to allow for tests to be marked as The tag should be to these tests.


Question: } } <ins> func TestCacherSendsMultipleWatchBookmarks(t *testing.T) { backingStorage := &dummyStorage{} cacher, _, err := newTestCacher(backingStorage, 1000) if err != nil { t.Fatalf("Couldn't create cacher: %v", err) } defer cacher.Stop() // Update bookmarkFrequency to speed up test. // Note that the frequency lower than 1s doesn't change much due to // resolution how frequency we recompute. cacher.bookmarkWatchers.bookmarkFrequency = time.Second // Wait until cacher is initialized. cacher.ready.wait() pred := storage.Everything pred.AllowWatchBookmarks = true makePod := func(index int) *examplev1.Pod { return &examplev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:            fmt.Sprintf("pod-%d", index), Namespace:       "ns", ResourceVersion: fmt.Sprintf("%v", 100+index), }, } } // Create pod to initialize watch cache. if err := cacher.watchCache.Add(makePod(0)); err != nil { t.Fatalf("failed to add a pod: %v", err) } ctx, _ := context.WithTimeout(context.Background(), 10*time.Second) w, err := cacher.Watch(ctx, "pods/ns", "100", pred) if err != nil { t.Fatalf("Failed to create watch: %v", err) } // Create one more pod, to ensure that current RV is higher and thus // bookmarks will be delievere (events are delivered for RV higher // than the max from init events). if err := cacher.watchCache.Add(makePod(1)); err != nil { t.Fatalf("failed to add a pod: %v", err) } timeoutCh := time.After(5 * time.Second) lastObservedRV := uint64(0) // Ensure that a watcher gets two bookmarks. for observedBookmarks := 0; observedBookmarks < 2; { select { case event, ok := <-w.ResultChan(): if !ok { t.Fatal("Unexpected closed") } rv, err := cacher.versioner.ObjectResourceVersion(event.Object) if err != nil { t.Errorf("failed to parse resource version from %#v: %v", event.Object, err) } if event.Type == watch.Bookmark { observedBookmarks++ if rv < lastObservedRV { t.Errorf("Unexpected bookmark event resource version %v (last %v)", rv, lastObservedRV) } } lastObservedRV = rv case <-timeoutCh: t.Fatal("Unexpected timeout to receive bookmark events") } } } </ins> func TestDispatchingBookmarkEventsWithConcurrentStop(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.WatchBookmark, true)() backingStorage := &dummyStorage{}


Question: } }) <del> It("should not start app containers if init containers fail on a RestartAlways pod", func() { </del> <ins> /* Release: v1.12 Testname: init-container-fails-stops-app-restartalways-pod Description: Ensure that app container is not started when all InitContainers failed to start and Pod has restarted for few occurrences and pod has restart policy as RestartAlways. */ framework.ConformanceIt("should not start app containers if init containers fail on a RestartAlways pod", func() { </ins> By("creating the pod") name := "pod-init-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Evaluating e2e tests based on available options which are covering important aspects with user scenarios and eligible to promote for conformance. What you expected to happen: These 4 e2e tests evaluate different and based on . [NodeConformance] should invoke init containers on a RestartNever pod [NodeConformance] should invoke init containers on a RestartAlways pod [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod Anything else we need to know?: comment, Are these tests good to promote for conformance or do we need to look on other aspects as well ? are observed api endpoint hits during tests execution. (API coverage improvement) - InitContainer [NodeConformance] should invoke init containers on a RestartNever pod InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod InitContainer [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod InitContainer [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod /area conformance cc
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
Go ahead and open a PR to ask this question. Yes == PR is merged, no == PR is closed (or amended to doc the reason these tests can't be promoted)


Question: totalConfTests, totalLegacyTests, missingComments int // If a test name contains any of these tags, it is ineligble for promotion to conformance <del> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Disruptive|Feature:[^]]+|Flaky)]`) </del> <ins> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Feature:[^]]+|Flaky)]`) </ins> ) const regexDescribe = "Describe|KubeDescribe|SIGDescribe"


Question: totalConfTests, totalLegacyTests, missingComments int // If a test name contains any of these tags, it is ineligble for promotion to conformance <del> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Disruptive|Feature:[^]]+|Flaky)]`) </del> <ins> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Feature:[^]]+|Flaky)]`) </ins> ) const regexDescribe = "Describe|KubeDescribe|SIGDescribe"


Question: } else { // Unable to get the priority class for reasons other than "not found". klog.Warningf("unable to get PriorityClass %v: %v. Retrying...", pc.Name, err) <del> return false, err </del> <ins> return false, nil </ins> } } }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: I've bootstrapped a cluster with kubeadm on a banana pi, it is up and running. Upon restarting, some process is slow that kube-apiserver does not boot up, exits with last lines: What you expected to happen: Expected the kube-apiserver to start up. How to reproduce it (as minimally and precisely as possible): On a banana pi (A20) bootstrap a cluster with kubeadm, add kube-router cni, and then restart kubelet. Anything else we need to know?: The version below contains a proposed fix, that is why the GitVersion is dirty. Environment: Kubernetes version Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"} Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.2-beta.0.1+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-12-18T19:10:37Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"} Cloud provider or hardware configuration: Banana pi m1 plus OS (e.g. from /etc/os-release): PRETTYNAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSIONID="9" VERSION="9 (stretch)" ID=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" Kernel (e.g. ): Linux k8s-master 4.9.0-8-armmp SMP Debian 4.9.130-2 (2018-10-27) armv7l GNU/Linux Install tools: kubeadm Others: Seems that in AddSystemPriorityClasses() adds a function which uses wait.Poll. On line 95 it logs 'Retrying...', howewer the return statement tells wait.Poll() to stop polling.


Question: } else { // Unable to get the priority class for reasons other than "not found". klog.Warningf("unable to get PriorityClass %v: %v. Retrying...", pc.Name, err) <del> return false, err </del> <ins> return false, nil </ins> } } }

<!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig api-machinery
/cc
If we solve it, we want a piece of pie :)


Question: } m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

CRI supports AppArmor, Seccomp and Sysctls via annotations , we should move them to typed and structured fields instead. (refer ) [x] Apparmor () [x] Sysctls () [x] Seccomp () cc
/cc
/sig node
Seccomp is addressed at .


Question: } m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Seccomp profile is passed to runtime by in CRI: is relative to node's local seccomp profile root, it is defined in kubelet. But runtime doesn't know it. We should pass full profile path in CRI. cc/ Will file a PR to fix this later.
Add support for Seccomp sounds like a new feature. The milestone should be reset to , correct?
not really. The current implementation supports seccomp already. If it's missing critical information to function properly, this would be a bug.
are we blocking releases for CRI in 1.5? i was not sure, so marking this as non-release-blocker and leaving 1.5 milestone. please correct if i am mistaken.
I don't get why this is a 1.5 targetted thing myself. Yes we want CRI to be in a good state in 1.5, but afaik we have zero intention of anyone actually using (at the very least because of the lack of exec auth regressing kubelet security). why should this be part of 1.5?
First, this is a small enough change that allows non-docker integrations to properly support seccomp. Second, if "we have zero intention of anyone actually using" is a valid reason, we should never fix any bugs in CRI. We do want people to try using it (perhaps not in production yet). However, given that seccomp is only in alpha, I am ok with dropping this and just continue the docker support for now.
Perhaps I misunderstood the meaning of code freeze, but I thought it was only bug-fixes regardless of size of change (or exceptions that have gone through some process) What I meant is we don't intend this to be used generally as part of the 1.5 release. Because of that, I don't think we should consider bugs in CRI bugs for the purpose of the 1.5 release freeze. My statement is just that we shouldn't violate code-freeze for this. We should totally fix this right after the 1.5 freeze window ends, and saying that I'm arguing we should never fix anything is disingenuous and taking it to an absurd extreme.
the only thing we don't seem to agree on is whether seccomp support was considered to be supported for CRI in 1.5.


Question: } m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

My interpretation is that we assumed seccomp would be supported until we found out that it wouldn't for other runtimes due to the lack of profile path. That's the only reason why I considered this a bug. Of course we could say that this is not really an important feature in CRI, so we can drop it, but we can be more clear on that.
If there's a bug in a feature no one uses, does fixing it make a sound? I think what we're not agreeing on is the role of CRI in 1.5. I understood it as something that is not generally usable. We can't recommend a customer use it, even as an experimental feature, due to security aspects (if nothing else). Correct me if I'm wrong. It's a developer integration point, and developers integrating with it are doing so with the kubernetes master branch, not with some release. Those reasons together result in my opinion that CRI is still not really a customer/release feature, and thus bugs or features related to it should not be exceptions to the freeze window, but rather should targeted at master as soon as the freeze lifts. If this were already post-freeze, would we be cherry-picking this over to 1.5?
This is not true. cri-o is depending on this fix for apparmor support.
is it depending on the 1.5 release branch directly, or on master?
I think it's better to make this in 1.5, so cri-o could work with first release with experimental CRI. It helps to encourage people to use CRI and find features misses or bugs.
Modifying the user-specified annotation is a little bit unsettling. I think adding a new annotation explicitly for the path would be better. Or, we should just add an explicit field for this. I spoke to and separately. I still think this is a bug fix, but we may want to be more careful about the fix. Given the time constraint, let's just list this as a known issue and work on it for 1.6.
OK, let's move this to next release and think carefully about seccomp feature besides this: kubelet may just pass the profile as string via CRI; may assume the profile locate in a file in a known format and pass path to the runtime; or maybe some other solutions.


Question: } m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

We need to clearly define it. define profile format clearly
Please document known issues for 1.5 in
(copied from ) And let's move here to discuss how to pass profiles to runtime. Related with .
This is issue is related with two level APIs: CRI, since we may also want to support profiles from ConfigMaps, I think we should pass full profile contents instead of path to runtime. issues is also related with seccomp api in kube-apiserver, it is based on annotations today. We should define seccomp profile format clearly (see ) and decide whether to add struct types to pod spec or just continue the annotations way. I think it's more clear to add specific struct types to pod spec.
Agreed - the path stuff is really a crutch (and implementation-specific) - I think is the answer here.
I don't disagree, but it's not strictly a requirement for supporting ConfigMaps (kubelet could create a file with the contents). An open question is whether to pass it as a raw string, or wait for and pass the structured data. The annotations way is deprecated (). I think the bigger question is where/how to put the data. E.g. structured data in the API, unstructured (string type) data in the API, reference to another object (e.g. ConfigMap). If the Kubelet needs to parse the spec, I think that's a good argument for a structured data type (either a standalone object or embedded in the pod API).
Yes, already opened to replace annotations with typed structs. I personally prefer a structured data type in both kubernetes API and CRI. WDYT?
A counter argument is that as the spec grows or new features are , we need to keep updating the Kubernetes API to maintain parity, or update the code in each CRI implementation to translate the Kubernetes spec. OTOH, if we use unstructured data we can use 3rd party libraries to parse out the data we need (assuming the spec evolves in a backwards compatible way).
What spec?
Whichever seccomp profile spec is being implemented by runtimes. E.g. if we decide to base the Kubernetes seccomp profile API off the OCI seccomp profile spec, and OCI adds some new features, at some point we'd probably want to add those features to Kubernetes.


Question: } m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

It also means that if different runtimes support different feature sets, we'll be stuck either tracking only the common features, or specifying features that may be ignored by the runtime. This may be a non-issue if the seccomp feature set rarely changes.
Well, yes, but that applies to everything in the CRI, and is one of the tradeoffs we ma[d|k]e by introducing this abstraction in the first place.
My $0.02: Moving the existing logic/information for seccomp into a first-class field for CRI (as in ) is productive because of the known problems with the annotation approach. My initial proposal for seccomp support included a resource similar to what has proposed in kubernetes/community and we were unable to come to an agreement on the issue refers to here: I do not necessarily expect that we will be able to come to an agreement about the seccomp resource in time for 1.7, so I think we should proceed with and do backward compatible CRI changes later if we need to inject the content of the seccomp profile instead of the path. I think we would deeply regret embedding API surface to describe seccomp profiles in the Pod API :)


Question: t.Fatalf("Unexpected error validating the service %s %v", svc.Name, err) } } <ins> type serviceMergePatch struct { Spec specMergePatch `json:"spec,omitempty"` } type specMergePatch struct { Type         v1.ServiceType `json:"type,omitempty"` ExternalName string         `json:"externalName,omitempty"` } // tests success when converting ClusterIP:Headless service to ExternalName func Test_ServiceChangeTypeHeadlessToExternalNameWithPatch(t *testing.T) { controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() _, server, closeFn := framework.RunAnAPIServer(controlPlaneConfig) defer closeFn() config := restclient.Config{Host: server.URL} client, err := clientset.NewForConfig(&config) if err != nil { t.Fatalf("Error creating clientset: %v", err) } ns := framework.CreateTestingNamespace("test-service-allocate-node-ports", server, t) defer framework.DeleteTestingNamespace(ns, server, t) service := &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name: "test-123", }, Spec: v1.ServiceSpec{ Type:      v1.ServiceTypeClusterIP, ClusterIP: "None", Selector:  map[string]string{"foo": "bar"}, }, } service, err = client.CoreV1().Services(ns.Name).Create(context.TODO(), service, metav1.CreateOptions{}) if err != nil { t.Fatalf("Error creating test service: %v", err) } serviceMergePatch := serviceMergePatch{ Spec: specMergePatch{ Type:         v1.ServiceTypeExternalName, ExternalName: "foo.bar", }, } patchBytes, err := json.Marshal(&serviceMergePatch) if err != nil { t.Fatalf("failed to json.Marshal ports: %v", err) } _, err = client.CoreV1().Services(ns.Name).Patch(context.TODO(), service.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}) if err != nil { t.Fatalf("unexpected error patching service using strategic merge patch. %v", err) } } </ins>

<!-- 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 --Patching a Kubernetes service failed with I the following yaml documents Create an external name service Change to to an ClusterIP Service Try to change it back to an external name service Kubernetes version (use ):Cloud provider or hardware configuration:
/sig node /sig api-machinery
Unsure if Service is part of networking /sig networking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Unsure if Service is part of networking 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 network
/remove-sig node
/cc /triage accepted
It is part of networking :), actually this part of Services is being revisited these days /assign
ack.
/sig network
Please don't triage/accept issues unless you're SURE they are your sig's. This fell through cracks.
/assign
this does not repo on: Here is what i did: service (the same one above) the service and change to =OK the service and change to =OK I have also performed step 3 using and the result is also OK /triage needs-information
I was using client v1.21.0 - is it resolved in newer kubectl 1.21.x patches?
please do. And also please share the exact steps you used were you using kubectl edit? or replace? or patch?
It's in the description - kubectl apply
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted - working on a fix. 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
/triage accepted working on a fix
to confirm does the merged PR allow you to now change the type from to ? Or does it still produce an error with the difference it is reported properly vs. INTERNAL_ERROR? If it's the former can we cherry pick this PR back to supported K8s versions?


Question: t.Fatalf("Unexpected error validating the service %s %v", svc.Name, err) } } <ins> type serviceMergePatch struct { Spec specMergePatch `json:"spec,omitempty"` } type specMergePatch struct { Type         v1.ServiceType `json:"type,omitempty"` ExternalName string         `json:"externalName,omitempty"` } // tests success when converting ClusterIP:Headless service to ExternalName func Test_ServiceChangeTypeHeadlessToExternalNameWithPatch(t *testing.T) { controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() _, server, closeFn := framework.RunAnAPIServer(controlPlaneConfig) defer closeFn() config := restclient.Config{Host: server.URL} client, err := clientset.NewForConfig(&config) if err != nil { t.Fatalf("Error creating clientset: %v", err) } ns := framework.CreateTestingNamespace("test-service-allocate-node-ports", server, t) defer framework.DeleteTestingNamespace(ns, server, t) service := &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name: "test-123", }, Spec: v1.ServiceSpec{ Type:      v1.ServiceTypeClusterIP, ClusterIP: "None", Selector:  map[string]string{"foo": "bar"}, }, } service, err = client.CoreV1().Services(ns.Name).Create(context.TODO(), service, metav1.CreateOptions{}) if err != nil { t.Fatalf("Error creating test service: %v", err) } serviceMergePatch := serviceMergePatch{ Spec: specMergePatch{ Type:         v1.ServiceTypeExternalName, ExternalName: "foo.bar", }, } patchBytes, err := json.Marshal(&serviceMergePatch) if err != nil { t.Fatalf("failed to json.Marshal ports: %v", err) } _, err = client.CoreV1().Services(ns.Name).Patch(context.TODO(), service.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}) if err != nil { t.Fatalf("unexpected error patching service using strategic merge patch. %v", err) } } </ins>

the former and we should be able to cherry pick it.
for another look.
Cherry picks made: 22 21 20


Question: admissionapi "k8s.io/pod-security-admission/api" "github.com/onsi/ginkgo/v2" <ins> "github.com/onsi/gomega" </ins> ) var storageVersionServerVersion = utilversion.MustParseSemantic("v1.13.99")

[X] test approval issue : [X] test pr : 3 May 2023 [X] two weeks soak end date : 16 May 2023 [X] test promotion pr : [X] remove endpoint form file According to following two APIsnoop queries, there are still 12 APIResources endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 12 endpoints. The e2e logs for this test are listed below. This query shows the following apiresources endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 12 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/open For tracking the rest of the processes
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: // Default: "" // +optional TLSMinVersion string `json:"tlsMinVersion,omitempty"` <ins> // rotateCertificates enables client certificate rotation. The Kubelet will request a // new certificate from the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletClientCertificate feature // must be enabled. // Default: false // +optional RotateCertificates bool `json:"rotateCertificates,omitempty"` </ins> // serverTLSBootstrap enables server certificate bootstrap. Instead of self // signing a serving certificate, the Kubelet will request a certificate from // the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletServerCertificate feature // must be enabled. // Default: false <ins> // +optional </ins> ServerTLSBootstrap bool `json:"serverTLSBootstrap,omitempty"` // authentication specifies how requests to the Kubelet's server are authenticated // Defaults:

/kind cleanup What happened: and both require opt-in configuration knobs to the kubelet. They are kinda global settings, you probably either opt into dynamic cert rotation or you don't, so they qualify for being in the struct. The knob for enabling dynamic serving certs was (I fully support that :+1:). What you expected to happen: I'd like the same to happen to  to be consistent. (Also, we're planning to use the config file for the kubelet by default in kubeadm soon, and it'd be nice to be able to set this value then in a structured manner) /assign


Question: // Default: "" // +optional TLSMinVersion string `json:"tlsMinVersion,omitempty"` <ins> // rotateCertificates enables client certificate rotation. The Kubelet will request a // new certificate from the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletClientCertificate feature // must be enabled. // Default: false // +optional RotateCertificates bool `json:"rotateCertificates,omitempty"` </ins> // serverTLSBootstrap enables server certificate bootstrap. Instead of self // signing a serving certificate, the Kubelet will request a certificate from // the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletServerCertificate feature // must be enabled. // Default: false <ins> // +optional </ins> ServerTLSBootstrap bool `json:"serverTLSBootstrap,omitempty"` // authentication specifies how requests to the Kubelet's server are authenticated // Defaults:

Flag name: Help text: <Warning: Beta featureAuto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. This is part of migrating the Kubelet command-line to a Kubernetes-style API. The flag should either be migrated to the Kubelet's API group, or simply removed from the Kubelet. If this could be considered an instance-specific flag, or a descriptor of local topology managed by the Kubelet, see: If this flag is only registered in os-specific builds, see: /assign /sig node /kind feature /priority important-soon /milestone v1.11 /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: "fmt" "k8s.io/api/core/v1" "k8s.io/klog/v2" <ins> "k8s.io/kubernetes/pkg/kubelet/util/format" </ins> "k8s.io/kubernetes/pkg/securitycontext" )

when deploying a container that has runAsNonRoot but runs as root this error appears, but for pods with lots of containers it can be confusing which container failed, especially if there are 3-rd party webhooks that inject containers please add the container name to the message, making it
/sig api-machinery
/assign I can try this fix
I just submitted a pr, can you review it for me, is it as you expected?
thx, looks good!
/remove-sig api-machiner /sig node /area kubelet
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machiner /sig node /area 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
/remove-sig api-machinery


Question: // it does not have to be reimplemented. type counterRaiser struct { counter *metrics.Counter <del> reason  string </del> <ins> // programmatic id used in log and audit annotations prefixes id string // human readable explanation reason string </ins> } func (c *counterRaiser) IncreaseMetricsCounter(req *http.Request) { if req != nil && req.URL != nil { if hostname := req.URL.Hostname(); len(hostname) > 0 { <del> klog.Infof("invalid certificate detected while connecting to %q: %s", req.URL.Hostname(), c.reason) </del> <ins> prefix := fmt.Sprintf("%s.invalid-cert.kubernetes.io", c.id) klog.Infof("%s: invalid certificate detected connecting to %q: %s", prefix, hostname, c.reason) audit.AddAuditAnnotation(req.Context(), prefix+"/"+hostname, c.reason) </ins> } } c.counter.Inc()

go1.18 dropped support for certificates signed with the SHA-1 hash function - While this does improve security, and publicly trusted Certificate Authorities no longer issue such certificates, it is possible that user-provided certificates issued by private Certificate Authorities and used in webhooks or aggregated API servers do still use this. Similar to removal of support for certificates without subjectAltNames in go1.17, we need to: [x] add metrics when webhook/conversion/aggregated certificates with this hash are encountered - [x] document use of and the metric from 1 as a mitigation for clusters which still need to identify and replace use of such certificates - to release note and known issues [x] add audit annotation when SHA-1 cert is encountered - [x] update docs at and - /sig api-machinery instrumentation docs /priority important-soon /milestone v1.24 /kind bug documentation Upgraded 1.23 clusters to continue working as-is Configure an admission webhook, conversion webhook, or aggregated server with a serving certificate signed with the SHA-1 hash function. Upgrade to HEAD of 1.24. The certificate will no longer work by default No response 24 HEAD (go1.18-based) n/a n/a No response No response No response
it looks like NewMissingSANRoundTripperWrapperConstructor already has all the plumbing, and instead of missing SANs we could check the SignatureAlgorithm and output a distinct metric
had a not-yet-tested WIP branch at with a sketch of what it might look like
/assign who offered to pick this up
GitHub didn't allow me to assign the following users: stlaz. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign who offered to pick this up 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
Indeed, please, you should trust Jordan :slightlysmilingface:
/assign
/triage accepted
These restrictions are on the GitHub side, this message is posted when it receives a specific error from the GitHub API while attempting to assign It is an annoying GitHub limitation, and one that seemingly does not exist in the web client vs the API.