jiebi/CodeConvo huggingface dataset:
Change:
podsPerNode: 35, cpuLimits: framework.ContainersCPUSummary{ stats.SystemContainerKubelet: {0.50: 0.12, 0.95: 0.14}, <del> stats.SystemContainerRuntime: {0.50: 0.06, 0.95: 0.08}, </del> <ins> stats.SystemContainerRuntime: {0.50: 0.05, 0.95: 0.07}, </ins> }, // We set the memory limits generously because the distribution // of the addon pods affect the memory usage on each node. memLimits: framework.ResourceUsagePerContainer{ <del> stats.SystemContainerRuntime: &framework.ContainerResourceUsage{MemoryRSSInBytes: 100 * 1024 * 1024}, </del> <ins> stats.SystemContainerKubelet: &framework.ContainerResourceUsage{MemoryRSSInBytes: 70 * 1024 * 1024}, stats.SystemContainerRuntime: &framework.ContainerResourceUsage{MemoryRSSInBytes: 150 * 1024 * 1024}, </ins> }, }, { <del> // TODO(yujuhong): Set the limits after collecting enough data. </del> <ins> cpuLimits: framework.ContainersCPUSummary{ stats.SystemContainerKubelet: {0.50: 0.15, 0.95: 0.20}, stats.SystemContainerRuntime: {0.50: 0.06, 0.95: 0.09}, }, </ins> podsPerNode: 100, <ins> // We set the memory limits generously because the distribution // of the addon pods affect the memory usage on each node. memLimits: framework.ResourceUsagePerContainer{ stats.SystemContainerKubelet: &framework.ContainerResourceUsage{MemoryRSSInBytes: 80 * 1024 * 1024}, stats.SystemContainerRuntime: &framework.ContainerResourceUsage{MemoryRSSInBytes: 300 * 1024 * 1024}, }, </ins> }, } for _, testArg := range rTests {

Discussion:
This is deterministically failing only in kubernetes-e2e-gce-serial with and so on. cc/
Docker 1.11 probably just has a higher resource footprint ()
We moved containerd to the docker cgroup in , and the build started to fail () I'll bump the memory limit now for docker 1.11.
Thanks Yu-ju, this issue got lost in the noise for me.
Change:
podLabels := map[string]string{"name": nginxImageName} d := newDeployment(deploymentName, 1, podLabels, nginxImageName, nginxImage, extensions.RollingUpdateDeploymentStrategyType, nil) d.Spec.Paused = true <del> tgps := int64(20) </del> <ins> tgps := int64(1) </ins> d.Spec.Template.Spec.TerminationGracePeriodSeconds = &tgps framework.Logf("Creating paused deployment %s", deploymentName) _, err := c.Extensions().Deployments(ns).Create(d)

Discussion:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
dup
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
All of these failures are related to the cleanup phase of the test - pods are terminating but never actually removed. We should probably use a zero grace period for pods.
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
Change:
for i := range pod.Spec.Containers { here := &pod.Spec.Containers[i] if here.Name == container.Name { <del> return fmt.Sprintf("spec.containers[%d]", i), nil </del> <ins> if here.Name == "" { return fmt.Sprintf("spec.containers[%d]", i), nil } else { return fmt.Sprintf("spec.containers{%s}", here.Name), nil } </ins> } } return "", fmt.Errorf("container %#v not found in pod %#v", container, pod)

Discussion:
Forked from ... The event generated from kubelet for BoundPod and displayed by kubectl should have Container(s) column ; otherwise, the user might think the entire pod is at the running state, but actually only one or some containers are running. When there are missing event(s) for failed containers, the thing gets worse. For example, in case, only net container is running. $ get events | grep testpd Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004
Change:
serviceNamespace: apiService.Spec.Service.Namespace, serviceAvailable: apiregistrationapi.IsAPIServiceConditionTrue(apiService, apiregistrationapi.Available), } <ins> if r.proxyTransport != nil && r.proxyTransport.DialContext != nil { newInfo.restConfig.Dial = r.proxyTransport.DialContext } </ins> newInfo.proxyRoundTripper, newInfo.transportBuildingError = restclient.TransportFor(newInfo.restConfig) <del> if newInfo.transportBuildingError == nil && r.proxyTransport != nil && r.proxyTransport.DialContext != nil { switch transport := newInfo.proxyRoundTripper.(type) { case *http.Transport: transport.DialContext = r.proxyTransport.DialContext default: newInfo.transportBuildingError = fmt.Errorf("unable to set dialer for %s/%s as rest transport is of type %T", apiService.Spec.Service.Namespace, apiService.Spec.Service.Name, newInfo.proxyRoundTripper) glog.Warning(newInfo.transportBuildingError.Error()) } </del> <ins> if newInfo.transportBuildingError != nil { glog.Warning(newInfo.transportBuildingError.Error()) </ins> } r.handlingInfo.Store(newInfo) }

Discussion:
/kind bug What happened: kube-aggregrator returns 500 status code with message: unable to set dialer for wardle/api as rest transport is of type *transport.debuggingRoundTripper What you expected to happen: 500 status code should not returned How to reproduce it (as minimally and precisely as possible): kube-apiserver with flag: sample-apiserver as said. command and get the 500 status code: Environment: community master
/assign
/sig api-machinery
/cc
Change:
spec: containers: - name: pause-win <del> image: gcr.io/gke-release/pause-win:1.2.0 </del> <ins> image: gcr.io/gke-release/pause-win:1.5.1 </ins> nodeSelector: kubernetes.io/os: windows tolerations:

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add Support for Windows Server version 2004 and 20H2. Why is this needed: Windows Server version 1909 is going end of life.
/sig windows /triage accepted
Change:
}) } <ins> func waitForConfigMapInNamespace(c clientset.Interface, ns, name string, timeout time.Duration) error { fieldSelector := fields.OneTermEqualSelector("metadata.name", name).String() lw := &cache.ListWatch{ ListFunc: func(options metav1.ListOptions) (object runtime.Object, e error) { options.FieldSelector = fieldSelector return c.CoreV1().ConfigMaps(ns).List(context.TODO(), options) }, WatchFunc: func(options metav1.ListOptions) (i watch.Interface, e error) { options.FieldSelector = fieldSelector return c.CoreV1().ConfigMaps(ns).Watch(context.TODO(), options) }, } ctx, cancel := watchtools.ContextWithOptionalTimeout(context.Background(), timeout) defer cancel() _, err := watchtools.UntilWithSync(ctx, lw, &v1.ConfigMap{}, nil, func(event watch.Event) (bool, error) { switch event.Type { case watch.Deleted: return false, apierrors.NewNotFound(schema.GroupResource{Resource: "configmaps"}, name) case watch.Added, watch.Modified: return true, nil } return false, nil }) return err } </ins> func waitForServiceAccountInNamespace(c clientset.Interface, ns, serviceAccountName string, timeout time.Duration) error { fieldSelector := fields.OneTermEqualSelector("metadata.name", serviceAccountName).String() lw := &cache.ListWatch{

Discussion:
Originally posted by in
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig testing /cc
/hold I have a subtly different fix in :)
Oh wait, this is an issue. Yay, thanks :). Fixed in
Change:
fs.BoolVar(&s.EnableProfiling, "profiling", true, "Enable profiling via web interface host:port/debug/pprof/.") fs.BoolVar(&s.EnableContentionProfiling, "contention-profiling", false, "Enable lock contention profiling, if profiling is enabled.") fs.StringVar(&s.ClusterCIDR, "cluster-cidr", s.ClusterCIDR, "CIDR Range for Pods in cluster.") <ins> fs.StringVar(&s.ClusterName, "cluster-name", s.ClusterName, "The instance prefix for the cluster.") </ins> fs.BoolVar(&s.AllocateNodeCIDRs, "allocate-node-cidrs", false, "Should CIDRs for Pods be allocated and set on the cloud provider.") fs.StringVar(&s.Master, "master", s.Master, "The address of the Kubernetes API server (overrides any value in kubeconfig).") fs.StringVar(&s.Kubeconfig, "kubeconfig", s.Kubeconfig, "Path to kubeconfig file with authorization and master location information.")

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is used by servicecontroller and routecontroller, for controller-manager, we have an option to set it, but for cloud-controller-manager, it will always be of default value 'kubernetes'. Here are some examples where it was in use: aws: azure: gce: openstack What you expected to happen: Having an option to set the value. How to reproduce it (as minimally and precisely as possible):
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cluster-lifecycle /area cloudprovider
oops looks like a PR ready already :)
Change:
--system-cgroups=/system  --cgroup-root=/  --network-plugin=$NETWORK_PLUGIN  <del> --network-plugin-dir=$NETWORK_PLUGIN_PATH  </del> <ins> --cni-conf-dir=$CNI_CONF_DIR  --cni-bin-dir=$CNI_BIN_DIR  </ins> --v=$log_level  --logtostderr

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.
Change:
secret := GetObjectFromChan(c).(*api_v1.Secret) return secret } <ins> // Wait till the store is updated with latest secret. func WaitForSecretStoreUpdate(store util.FederatedReadOnlyStore, clusterName, key string, desiredSecret *api_v1.Secret, timeout time.Duration) error { retryInterval := 100 * time.Millisecond err := wait.PollImmediate(retryInterval, timeout, func() (bool, error) { obj, found, err := store.GetByKey(clusterName, key) if !found || err != nil { return false, err } equal := secretsEqual(*obj.(*api_v1.Secret), *desiredSecret) return equal, err }) return err } </ins>

Discussion:
https://k8s- Failed: TestSecretController {secret} Previous issues for this test:
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
This flake seems to have started after merged (just looking at the merge time line). Can you please take a look?
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
Sorry just saw this, looking at it now
Sent for a fix
nice thanks
Change:
}, status: "Unknown,SchedulingDisabled", }, <ins> { node: api.Node{ ObjectMeta: metav1.ObjectMeta{ Name:   "foo12", Labels: map[string]string{"kubeadm.alpha.kubernetes.io/role": "node"}, }, Status: api.NodeStatus{Conditions: []api.NodeCondition{{Type: api.NodeReady, Status: api.ConditionTrue}}}, }, status: "Ready,node", }, </ins> } for _, test := range table {

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This has been fixed in recent versions
Change:
return nil, err } if e.Decorator != nil { <del> return newDecoratedWatcher(w, e.Decorator), nil </del> <ins> return newDecoratedWatcher(ctx, w, e.Decorator), nil </ins> } return w, nil }

Discussion:
Using the Fabric8 client, which defaults to using WebSockets for Watches, I established a Watch on Service resources. After the timeout (implicit or explicit) rather than the WebSocket seeing a close control frame or even an EOF it continued to be open and fulfill ping/pong requests - but no Service events are sent. The WebSocket would close. Create a WebSocket based Watch with the ListOptions timeoutSeconds set on the Service resource along with a steady production of Service events, such as create/delete of a dummy Service. Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-10-27T05:15:27Z", GoVersion:"go1.15.0", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2021-01-13T13:20:00Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"} The behavior has been seen in both local minikube and OpenShift distributions based upon Kubernetes 1.20. OS (e.g: ): Fedora 33
/sig api-machinery
Is this the same issue as ?
It could be related, but in that case the client is calling close. In this case we expect the server to initiate the close.
A couple of things were discussed when we triaged this issue: a) we need to involve the Fabric8 team (~java client?) b) We don't always default to Websocket, in fact we discussed discontinuing it c) But the code is still there, so it's allowed for now and we should support it. Not sure what to do next
a) no, it sounds like an apiserver problem, it should be reproducible with a go client in a test. b) If anything, we should standardize on websockets. Brower based clients depend on them. And when/if we get rid of SPDY, websockets are the replacement. This may be relevant to interests.

I didn't see an option to use websockets with the go client the impl is at Is there another code path or go client that will use a websocket for Watches?
Technically I didn't say our go client, just a go client. I just had in mind using the raw websockets library. must be testing the websocket watches somehow?
I adapted to It will simply keep running - with no events after the timeout. If you switch to configmap, it will terminate.
that's a terrific reproducer, thanks!
Yeah, we should absolutely be able to stick that in a unit / integration test somewhere, thanks!
opened in configmap watch works correctly, service watch hits timeout without the server closing the connection
I suspect the issue is in newDecoratedWatcher. Services implement a decorator and configmaps don't.
yup, the request context wasn't propagated to the decorated watcher
Service decorator was in 1.20 in Fix with unit and integration test in Will pick to 1.21 and 1.20 once merged
/triage accepted
Change:
} <del> func (s *SecureServingOptions) AddDeprecatedFlags(fs *pflag.FlagSet) { fs.IPVar(&s.BindAddress, "public-address-override", s.BindAddress, "DEPRECATED: see --bind-address instead.") fs.MarkDeprecated("public-address-override", "see --bind-address instead.") } </del> // ApplyTo fills up serving information in the server configuration. func (s *SecureServingOptions) ApplyTo(c *server.Config) error { if s == nil {

Discussion:
Currently as authentication and authorization are both standard config for all clusters, the kubeapiserver insecure http handler is unsecure, which means the cluster is vulnerable to the attack. So it should be deprecated, even removed totally.
/sig api-machinery
I think removing the insecure option is a good idea. Can you send an email the sig-apimachinery mailing list with a proposed timeline? I think this should be like other GA features and have a one year clock.
Sure, I will send it ASAP.
:+1:
Change:
} type MetadataOpts struct { <del> SearchOrder string `gcfg:"search-order"` </del> <ins> SearchOrder    string     `gcfg:"search-order"` RequestTimeout MyDuration `gcfg:"request-timeout"` </ins> } // OpenStack is an implementation of cloud provider Interface for OpenStack.

Discussion:
What happened: We use OpenStack as our cloud provider. We meet an issue that some controllers stuck because all workers routine stuck at http call to OpenStack services because of rabbitmq issues. Stuck routine call stack: Checked the openstack cloud provider that there is no HttpClient.Timeout set which means no timeout during http call. I think we should set at least the default http timeout value. Environment: Kubernetes version (use ): v1.6.3 Cloud provider or hardware configuration**: OpenStack
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig openstack /kind feature PTAL PR .
Change:
record_command run_kubectl_explain_tests fi <ins> ############################## # CRD Deletion / Re-creation # ############################## if kube::test::if_supports_resource "${namespaces}" ; then record_command run_crd_deletion_recreation_tests fi </ins> ########### # Swagger #

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Changing the scope field of a CRD ist not possible since it's immutable. But even after deleting and re-creating the CRD with changed scope it doesn't let me create resources of the CRD's kind. Re-creating CRD with changed scope should just work. Here is a full example that in the end leads to the error when trying to create a resource after re-creating the CRD. Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: vSphere 7.0 OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1160.42.2.el7.x86_64
/sig api-machinery
/assign /triage accepted
This appears to be working as intended. The example custom resource you use: It Cluster scoped because it has no namespace. But once the CRD is namespace scoped, you should not be able to create cluster scoped custom resources of that type. If instead you add a namespace to Example, it should be created, e.g.:
if the above seems to have answered your question - please feel free to close the issue :) Thank you!
kubectl will automatically use the namespace so this is definitely not the issue here. I can reproduce this issue with my above script in a fresh (v1.22.2) cluster. You can add the namespace in the last manifest, it makes no difference. From my understanding this really seems to be a bug.
Yes, that's true. Good catch. Okay, we need to root cause this.
I tried using curl to create the custom resource directly against the API and got the same result: So the problem seems to be in the API server (not in kubectl).
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