Question: } ret := make(map[corev1.ObjectReference]rest.ResponseWrapper, 1) <del> ret[*ref] = clientset.Pods(t.Namespace).GetLogs(t.Name, opts) </del> <ins> ret[*ref] = clientset.Pods(t.Namespace).GetLogs(t.Name, currOpts) </ins> return ret, nil }

/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: }, } } <ins> func checkLimitRangeListQuantity(f *framework.Framework, label string, quantity int) func() (bool, error) { return func() (bool, error) { framework.Logf("Requesting list of LimitRange to confirm quantity") list, err := f.ClientSet.CoreV1().LimitRanges(f.Namespace.Name).List(context.TODO(), metav1.ListOptions{LabelSelector: label}) if err != nil { return false, err } if len(list.Items) != quantity { return false, nil } framework.Logf("Found %d LimitRange with label %q", quantity, label) return true, nil } } </ins>

4 Oct 2022 [x] Two weeks soak end date: 18 Oct 2022 [x] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. listCoreV1LimitRangeForAllNamespacespatchCoreV1NamespacedLimitRangedeleteCoreV1CollectionNamespacedLimitRange Using a number of existing e2e test practices a new has been created for three LimitRange endpoints. The e2e logs for this test are listed below. This query shows which LimitRange endpoints are hit within a short period of running this e2e test example endpoint | useragent --------------------------------------------+
createCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection deleteCoreV1CollectionNamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1LimitRangeForAllNamespaces | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection patchCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection (5 rows) If a test with these calls gets merged, test coverage will go up by 3 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: func (plugin *cinderPlugin) newUnmounterInternal(volName string, podUID types.UID, manager cdManager, mounter mount.Interface) (volume.Unmounter, error) { return &cinderVolumeUnmounter{ &cinderVolume{ <del> podUID:  podUID, volName: volName, manager: manager, mounter: mounter, plugin:  plugin, </del> <ins> podUID:          podUID, volName:         volName, manager:         manager, mounter:         mounter, plugin:          plugin, MetricsProvider: volume.NewMetricsStatFS(getPath(podUID, volName, plugin.host)), </ins> }}, nil }

Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: I am trying to get metrics working. According this there should be support after 1.8 kube. However, I am now using kube 1.10.1 and still I cannot see anything in ? Should these be there or not? What you expected to happen: I except that kubelet should expose prometheus metrics to /metrics path as well. Then it is easy to read with prometheus. How to reproduce it (as minimally and precisely as possible): Create new cinder volume, attach it to pod and try to query result from in kubelet Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): centos 7 Kernel (e.g. ): Install tools: Others:
cc
/sig storage
Prometheus metrics should be available on default port of Kubelet. Can you try ? If you are on a RBAC enabled cluster (such as openshift) you may have to use token or key to authenticate for fetching metrics.
returns many metrics but there is not things. There is one pod which have cinder volume attached running in that node. So there should be some metrics right?
It appears that Cinder volume plugin does not implement metric interface necessary for getting those stat metrics - This seems like an oversight and is fairly easy to fix. I can help getting the PR merged if you can open it.
/sig openstack
Kubernetes v1.19.16 there is no kubelet_volume* metrics in //metrics how to fix it???


Question: var lastEndpoints []api.Endpoints sleep := 5 * time.Second <ins> // Used to avoid spamming the error log file, makes error logging edge triggered. hadSuccess := true </ins> for { data, err := ioutil.ReadFile(s.filename) if err != nil { <del> glog.Errorf("Couldn't read file: %s : %v", s.filename, err) </del> <ins> msg := fmt.Sprintf("Couldn't read file: %s : %v", s.filename, err) if hadSuccess { glog.Error(msg) } else { glog.V(1).Info(msg) } hadSuccess = false </ins> time.Sleep(sleep) continue } <ins> hadSuccess = true </ins> if bytes.Equal(lastData, data) { time.Sleep(sleep)

We have , but there isn't a label in the k/k repo. There is only . Do we need to add a label or rename to ?
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig ui :smiley:
/sig contributor-experience
/cc
I just it. Fixed?
Yeah. BTW, the page has a bad md format. It also should be fixed.
Feel free to send a PR to fix :)
As Piotr is the owner, I thought let him fix:) If it's Okay, I will do. Thanks Christoph!
anyone can contribute to the kubernetes/community repo too :) the PR would be reviewed like any other (usually the sig-lead for that sig would review)
Okay:)
Yep just fix things when you can. That's just faster :)
FWIW this lead me to open

I can see that this message is flooding my minion logs so I was curious what should this config file looks like. I was trying to find some example, but with no luck. Also is this config file created during the runtime? What actually creates it? Shouldn't we just give up when the config file does not exists? Also there are better ways (maybe) to do polling if the file exists or not. I meaning you can use inotify () instead of an infinite loop + sleep. I'm happy to make a patch if you think it is a good idea. PS: I know that you put the timeout 5 seconds before retries.
Thanks for the report. I think this is just a bug-- we should check whether it exists and not pollute the log. I'm pretty sure we don't currently even use that file. Also we should NOT be reading the proxy's config from a file in /tmp where anybody can write it. Bad default location.
Proxy config sounds like an /etc thing, same for kubelet's container manifests from disk
Are we interested in polling for the configuration files changes? Or do we want to read the settings just once, as an ordinary unix binary?
Yes, polling is a requirement. This is a live config file like the kubelet's machine files.


Question: ################# record_command run_impersonation_tests <ins> #################### # kubectl wait     # #################### record_command run_wait_tests </ins> kube::test::clear_all if [[ -n "${foundError}" ]]; then

We should consider updating the command to wait on all resources for a given kind. For example: would wait for every pod in the current namespace to be deleted. /sig cli cc
Interestingly, the error text implies that this is already supported: Yet when you try to use it, it declares Would really like the wait functionality given some much needed TLC. Still no way to determine what conditions are supported for various resources (eg. I can say and it just waits for the timeout like that resource might actually potato at some point).
I'm looking into adding the --all flag to wait, sounds like a nice feature to have :)


Question: # Emacs save files *~ <ins> #*# .#* </ins> # Vim-related files [._]*.s[a-w][a-z]

When I passing to kubelet, it did not respect the option, and still copy the to the pod. What makes it special is that the provided by myself is empty. After skimming the code, I found the logic here is problematic: Because is empty, an empty array and no error is returned. Then, if the dnsPolicy is (that is the default config for CoreDNS deployment), the turns to be : Then, containerd will get an empty , so it will copy from the host to the container: Finally, CoreDNS reports forwarding loop error. Kubelet should refuse to use the wrong empty to create a pod, and complains with errors. to kubelet, and make sure the specified file is empty. the output of CoreDNS, and its . No response_ <detailsk8s v1.28.2 containerd v1.7.6 </details<detailsNone </details<detailsAny major Linux distribution. </details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
/sig network
why if someone wants to pass an empty to the pods? is that a possibility? I do not know if kubelet should compensate what it seems an operator problem, or am I reading it wrong?
This situation MAY occur when systemd-resolved is used, and the operator pass the to kubelet. Although systemd-resolved create this file in manner of "create temp, write temp, rename" ... ... the UPLINK config () file may still be full of comments if there is no available name server at the time.
And after a while, systemd-resolved got an available dns server by any way, then the UPLINK config should be recreated, however the kubelet have taken the stale and full-of-comments .

I see there is a race there, thanks for the explanation ... the only question I have is if someone is relying on this behavior of passing an empty to the pods, a change like this will break it
/remove-sig node. This is on network team to decide how to migrate a new behavior for empty file..
Those labels are not set on the issue: <detailsIn response to : /remove-sig node. 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 node
If set , it means will use the default value , so this change may be not a break, but should be a warning.
It is suggesting to change the behavior to stop the pod creation
/assign But if already have design on this, please go ahead.
I still don't have clear what is the proposal and how to maintain compatibility
Cool, may be it's like new warning events just like , or something else.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
This is a fun bug, but not that hard to comprehend, I think. Forget whether it's a "good idea" or not. Is it valid to pass an empty file to ? If yes, should it mean the same as not passing that flag or should it mean "no config". I think it IS valid and it SHOULD mean "no config". What really happens is that kubelet gets empty slices (but no error, so not ambiguous). When it creates the DNSConfig message, it appears empty, because it is comprised entirely of fields with no instances. That is ambiguous - it could mean "no data" or "not specified". It's unclear to me if we can tell the difference between those? - do you know? can return nil.

Containerd further conflates those two by parsing into a string, and assuming means "not specified". Even if it WAS specified! Then, containerd "helpfully" decides that, if you don't specify any contents, it should copy the host's I am not 100% confident in CRI semantics - is it valid for CRI to NOT populate the message? Or is that effectively required? If a CRI caller does not specify , is the CORRECT behavior to go look at the host? That seems like over-stepping, to me. If I wanted a DNS config, I would have sent it. Agree or disagree? So IMO, the fix here is either (in my pref order): 1) containerd should not fall back on host's AT ALL 2) containerd should differentiate "not provided" from "provided and empty" ( returned nil) 3) we should add a "this struct intentionally left blank" marker to , so containerd can do the above So I think this very much is a SIG Node issue. /sig node As to the question of how this problem was are you setting the kubelet to an empty rather than just configuring the specific Pods in question?
This is because CoreDNS reports a forwarding loop issue due to systemd-resolved is used in the node, and I pass to kubelet. But it has a race condition here when the node restarted, the file may be full of comments if there is no available name server at the time. And after a while, systemd-resolved got an available dns server by any way, then the UPLINK config should be recreated, however the kubelet have taken the stale and full-of-comments . Of course passing an empty is incorrect, but it is not deliberately.
Fixed in containerd
you should check if you need to fix this too in cri-o ^^^
It looks like . I'm going to create a PR in .
Thank you and thanks for the hint! :heart:


Question: } volume := Volume{ <del> ID:     volumeV2.ID, Name:   volumeV2.Name, Status: volumeV2.Status, Size:   volumeV2.Size, </del> <ins> AvailabilityZone: volumeV2.AvailabilityZone, ID:               volumeV2.ID, Name:             volumeV2.Name, Status:           volumeV2.Status, Size:             volumeV2.Size, </ins> } if len(volumeV2.Attachments) > 0 {

Resizing a persistent volume is partially broken on openstack (cinder) with k8s v1.11.1. Partially in the sense that static resizing (requiring a pod restart) works, but the newly introduced online resizing (not requiring a pod restart) fails. Upon resizing a pvc it remains in the Resizing condition forever (see the warning event) until I delete the pod that has this pvc mounted: After pod deletion it notifies me (correctly) that it's now waiting for the pod to come up to finish resizing: So far the warning event does not break the ExpandPersistentVolumes feature, as this one anyhow requires a pod restart. However it breaks the newly introduced ExpandInUsePersistentVolumes feature (alpha with k8s v1.11; doesn't require a pod restart for resizing to finish), as the pvc will remain in "Resizing" condition forever (or until the pod is restarted but this defeats the purpose of ExpandInUsePersistentVolumes). I'm not sure whether this is fully related but upon digging around I found and a consecutive fix with which was merged on Jan 23. However a few days later this fix seems to be (probably accidentally) overwritten with this commit: /kind bug /sig storage /sig openstack
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
It is already fixed. So I will close it.
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I am trying cinder online pvc resizing on kubernetes1.12.2. I noticed this kubernetes version has include your fix, but I still failed to resize pvc online.

The error log has no change: Warning VolumeResizeFailed 45s (x2 over 66s) volumeexpand Error expanding volume "default/myclaim-expend" of plugin : volume status is not available The error log is reported below code line "volume.Status != volumeAvailableStatus" // ExpandVolume expands the size of specific cinder volume (in GiB) func (os *OpenStack) ExpandVolume(volumeID string, oldSize resource.Quantity, newSize resource.Quantity) (resource.Quantity, error) { volume, err := os.getVolume(volumeID) if err != nil { return oldSize, err } if volume.Status != volumeAvailableStatus { // cinder volume can not be expanded if its status is not available return oldSize, fmt.Errorf("volume status is not available") } One point confused me, once cinder volume is used by pod, it's status is "in-use", how the online pvc resizing pass the code check "volume.Status != volumeAvailableStatus"? There's where the online pvc resizing fails.
It looks like Cinder can not support online volume expansion - which is what is happening here. Even if online expansion is enabled, I think to actually perform resizing of Cinder volumes - you must bring the pod down.


Question: subjectAltName = @alt_names [alt_names] IP.1 = 127.0.0.1 <ins> DNS.1 = webhook-test.default.svc </ins> EOF # Create a certificate authority

xref: , The package is failing tests and doesn't seem to work as expected when run under go1.9. It throws some x509 certificate errors. However, the same tests run successfully under go1.8. go1.8 successful output: go1.9 failing output: /priority important-soon
/assign


Question: const ( CNIPluginName = "cni" <ins> // defaultSyncConfigPeriod is the default period to sync CNI config // TODO: consider making this value configurable or to be a more appropriate value. defaultSyncConfigPeriod = time.Second * 5 </ins> ) type cniNetworkPlugin struct {

What happened: When Node's iops is full, the Node status becomes to be NotReady. The NotReady message is "Container runtime is not ready". After our troubleshoot, we found func in cni package costs more then 30s, then the runtime status health check is failed : What you expected to happen: Node should still be in Ready status when iops is full. Because the CNI config files does not change. How to reproduce it (as minimally and precisely as possible): Run an application to fill disk IO bandwidth, then the Node becomes to be NotReady. Anything else we need to know?: Nothing yet. Environment: Runtime is dockershim. Other environment is no need to pay attention.
/assign /sig-node
/sig node /sig network


Question: namespace: default name: external-provisioner-cfg rules: <ins> # Only one of the following rules for endpoints or leases is required based on # what is set for `--leader-election-type`. Endpoints are deprecated in favor of Leases. </ins> - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "watch", "list", "delete", "update", "create"] <ins> - apiGroups: ["coordination.k8s.io"] resources: ["leases"] verbs: ["get", "watch", "list", "delete", "update", "create"] </ins> --- kind: RoleBinding

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-e2e-gce Which test(s) are failing: Since when has it been failing: unknown Testgrid link: Reason for failure: unknown Anything else we need to know: PR that introduces the new test: /assign /sig storage /kind flake /priority critical-urgent the job is PR blocking and is flaking mutliple times in a row.
/remove-kind bug
from SIG Testing mentioned that probably the whole job is timing out, so this might not be a SIG Storage problem per-se. we need the owners to triage the problem.
Here's one example run:
i've sent an email to k-dev to see who reacts. increasing the timeout is the preferred option for now.
To clarify I think this is a real failure that really happened at least twice, but it is likely not the primary cause of pull-kubernetes-e2e-gce currently being broken, and almost all failed pull-kubernetes-e2e-gce runs that I see had this test pass.
Let's use this bug to triage this specific test case
The first provision succeeded: 0404 18:32:48. 1 ] provision "multivolume-4799/pvc-mvjvq" class "multivolume-4799-csi-hostpath-multivolume-4799-scjmgx4": started The second one failed because it couldn't find the storage class: I0404 18:32:50. 1 ] provision "multivolume-4799/pvc-985xh" class "multivolume-4799-csi-hostpath-multivolume-4799-scm9tnq": started E0404 18:32:50. 1 ] provision "multivolume-4799/pvc-985xh" class "multivolume-4799-csi-hostpath-multivolume-4799-scm9tnq": error getting claim's StorageClass's fields: storageClass "multivolume-4799-csi-hostpath-multivolume-4799-scm9tnq" not found
The provisioner doesn't retry/requeue if the storageclass is not found.

I guess it is flaky because the pvc is created immediately after the sc and even though the provisioner has watches on both, it's possible it sees pvc before sc? It's a bug in the external library, not an issue with in-tree because it retries everything every 15s. So I'll need to update the library, update hostpath plugin, then update our manifests here. btw, how did you find that log
There is probably something else wrong too* because every other dynamic provisioning test creates pvc immediately after the sc. Why does only this one flake?
We store all the CSI driver logs for each test case under artifacts
Should we just add wait before and ? Or are there any ways to ensure that storageClass is ready? (like checking that storageClass can be got after creation.)
I don't think wait is the solution. Even if the test does a Get after Create, there is no guarantee that the provisioner pod's informer has seen the StorageClass too. I've opened for now I am still unsure why only this test is flaking frequently, if the issue is race between controller seeing PVC first or SC first, one would expect a lot of other external provisioner tests to fail too...
I guess given the frequency of failures, waiting for SC to exist after the Create call could be a good stopgap solution. Fixing the lib-hostpath plugin-test will take a lot more time.
Can we wait until 's actual fix for this issue or do we need workaround to reduce this flake?
Let's go with 's fix. I don't think it should take too long


Question: wantModules.Insert(ipvsModules...) loadModules.Insert(mods...) modules := wantModules.Difference(loadModules).UnsortedList() <del> if len(modules) != 0 { return false, fmt.Errorf("IPVS proxier will not be used because the following required kernel modules are not loaded: %v", modules) </del> <ins> var missingMods []string ConntrackiMissingCounter := 0 for _, mod := range modules { if strings.Contains(mod, "nf_conntrack") { ConntrackiMissingCounter++ } else { missingMods = append(missingMods, mod) } } if ConntrackiMissingCounter == 2 { missingMods = append(missingMods, "nf_conntrack_ipv4(or nf_conntrack for Linux kernel 4.19 and later)") } if len(missingMods) != 0 { return false, fmt.Errorf("IPVS proxier will not be used because the following required kernel modules are not loaded: %v", missingMods) </ins> } // Check ipset version

<!-- 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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)


Question: // For this test, we'll actually cycle, "list/watch/create/delete" until we get an RV from list that observes the create and not an error. // This way all the tests that are checking for watches don't have to worry about RV too old problems because crazy things *could* happen // before like the created RV could be too old to watch. <del> for _, version := range servedVersions(crd) { err := wait.PollImmediate(500*time.Millisecond, 30*time.Second, func() (bool, error) { return isWatchCachePrimed(crd, dynamicClientSet, version) }) if err != nil { return nil, err } </del> <ins> err = wait.PollImmediate(500*time.Millisecond, 30*time.Second, func() (bool, error) { return isWatchCachePrimed(crd, dynamicClientSet) }) if err != nil { return nil, err </ins> } return crd, nil } <ins> func resourceClientForVersion(crd *apiextensionsv1beta1.CustomResourceDefinition, dynamicClientSet dynamic.Interface, namespace, version string) dynamic.ResourceInterface { gvr := schema.GroupVersionResource{Group: crd.Spec.Group, Version: version, Resource: crd.Spec.Names.Plural} if crd.Spec.Scope != apiextensionsv1beta1.ClusterScoped { return dynamicClientSet.Resource(gvr).Namespace(namespace) } else { return dynamicClientSet.Resource(gvr) } } </ins> // isWatchCachePrimed returns true if the watch is primed for an specified version of CRD watch <del> func isWatchCachePrimed(crd *apiextensionsv1beta1.CustomResourceDefinition, dynamicClientSet dynamic.Interface, version string) (bool, error) { </del> <ins> func isWatchCachePrimed(crd *apiextensionsv1beta1.CustomResourceDefinition, dynamicClientSet dynamic.Interface) (bool, error) { </ins> ns := "" if crd.Spec.Scope != apiextensionsv1beta1.ClusterScoped { ns = "aval" } <del> gvr := schema.GroupVersionResource{Group: crd.Spec.Group, Version: version, Resource: crd.Spec.Names.Plural} var resourceClient dynamic.ResourceInterface if crd.Spec.Scope != apiextensionsv1beta1.ClusterScoped { resourceClient = dynamicClientSet.Resource(gvr).Namespace(ns) } else { resourceClient = dynamicClientSet.Resource(gvr) </del> <ins> versions := servedVersions(crd) if len(versions) == 0 { return true, nil </ins> } <ins> resourceClient := resourceClientForVersion(crd, dynamicClientSet, ns, versions[0]) </ins> instanceName := "setup-instance" instance := &unstructured.Unstructured{ Object: map[string]interface{}{ <del> "apiVersion": crd.Spec.Group + "/" + version, </del> <ins> "apiVersion": crd.Spec.Group + "/" + versions[0], </ins> "kind":       crd.Spec.Names.Kind, "metadata": map[string]interface{}{ "namespace": ns,

both in PR and CI runs see /assign
/assign
Interesting fact: is not flaky, only . The test codepath for these two are almost identical. I wonder if this is a real bug not a flaky test. still investigating.
still seeing flakes like https://k8s- the loop that ensures the watch cache is primed goes version-by-version, and creates and observes the delete event for that version. it does not ensure the delete event is drained from the watch caches for the other versions.
a better approach would be probably be to:
why the poll? Because the watch is not reliable? Otherwise, we have that structure now.
Moves the version loop inside the poll Today we loop over versions and poll per version, which can leave unconsumed delete events in prior versions
Cannot follow. Now we have the following without a poll:
At minimum, I would move the version loop inside the poll so that when we exit we know the deletion events from isWatchCachePrimed are consumed by the watch caches for all versions. If we wanted, we could move the create/delete up out of the isWatchCachePrimed function or pass versions into it to avoid creating/deleting an object per version
Ok, so we were talking about different code. good. To understand: we do a call per version, each creating and deleting an object, and waiting for the delete event with a watch call. a following watch will not see the events of the calls of itself (because they use the same versioned watch cache) and of any version in front of it in the version slice (is this true?), but it might see events of calls of versions later in the version slice. So with your outer poll and inner version loop we would make sure that we drain every version's cache for following rv=0 watch requests. Sounds plausible.
Where do we have the official watch axioms?
I think I know what is the problem here. We make sure the watch is primed for . then we move on to and make sure the watch is primed by creating another object in . The watch cache is drained for but the watch cache for is not and that is the problem here. will send a fix.
yep, same thing I described above. The solution looks good.
I didn't see your comment when I commented. Your description is accurate.


Question: # Dry-run create the CR kubectl "${kube_flags[@]:?}" apply --dry-run=server -f hack/testdata/CRD/resource.yaml "${kube_flags[@]:?}" # Make sure that the CR doesn't exist <del> ! kubectl "${kube_flags[@]:?}" get resource/myobj || exit 1 </del> <ins> ! kubectl "${kube_flags[@]:?}" get resource/myobj 2>/dev/null || exit 1 </ins> # clean-up kubectl "${kube_flags[@]:?}" delete customresourcedefinition resources.mygroup.example.com

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig cli /cc /milestone v1.20 /prority important-soon
after creating the CRD, before applying the CR, kubectl should wait until includes :
/assign
/assign is this issue related to ?
no, this is simply kubectl trying to apply a CR before the server has made the API available at all
Got it! and I have filed to address this issue.
Still happening:
still happening: looks like the root cause is not related to CRD: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: /reopen
Reopened this issue. <detailsIn response to : still happening: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
yes, the actual error is later: Line 177 succeeds, and the next line fails:


Question: if err != nil { return nil, err } <del> err = m.Start() if err != nil { return nil, err } </del> cadvisorClient := &cadvisorClient{ Manager: m,

This is blocking (reboot test). In running a test that reboots all of the nodes and then runs the e2e tests, we saw a failure with the influxdb / heapster monitoring test: The heapster logs, from running (), shows a ton of the following kubelet errors for all containers (this one happens to be for skydns): The shows a bunch of 500 errors, such as: However, the apiserver thinks that all the pods are running ( gives this ) Docker thinks that the pods are running ( on that node gives this ) In summary: apiserver and docker think containers are running but kubelet can't find them this manifested in the influxdb / heapster monitoring e2e test after node reboot I've still got the cluster around if anyone would like to debug. +cc (helped me debug this (thanks!)) +cc (node) +cc (interested in getting in, which this is blocking)
Can I access your test nodes?
Is this an active problem? I'd check if the cAdvisor thinks the containers exist (it is the one returning the error). I'd then scan the logs to see if cAdvisor had any errors related to that container.
Unfortunately during debugging, I restart kubelet service on that node, the issue is gone. The problem could be cadvisor cannot get stats, but I couldn't find any cadvisor related error messages. How easy to reproduce the issue here? Next time we might access cadvisor's page to see if there is no such container information. Thanks!
(and Thanks for looking into this! I believe I can reproduce easily but I'll confirm. Where do I look for cAdvisor info? I don't see a log in or , and I don't see a cAdvisor container running?
cAdvisor is running as part of kubelet now. If you can reproduce the issue, could you please change kubelet's log level to 4 so that we have more cadvisor log here? Thanks!
Yes! How do I do that?

I can reproduce this by doing the following: After this, I got two failures: ... and I have another node with more of the same kubelet errors: (If I need to change the Kubelet log level at compile-time I can do that and repro on a new cluster; otherwise, I've got another cluster with the issue that can be introspected...)
There is a race between cadvisor initialization and docker. cadvisor failed to register docker factory, and bailed out. is going to make cadvisor more resilient to the issue of docker is not available, and have some retry logic. I am going to change kubelet initialization logic a little bit to make sure docker is running before we start cadvisor.
Awesome, thank you Dawn! Are there issues or PRs I can follow to know when this is unblocked?
is one of them. is working on the second.


Question: add(t, dc.podStore, pod) dc.sync(ctx, pdbName) ps.VerifyNoStatusError(t, pdbName) <del> verifyUnsupportedControllerEventEmitted(t, dc) </del> <ins> verifyEventEmitted(t, dc, "UnmanagedPods") </ins> } // Check if the unmanaged pods are correctly collected or not

When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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: } return ContainerStatus{} } <ins> // IsPodReady retruns true if a pod is ready; false otherwise. func IsPodReady(pod *Pod) bool { for _, c := range pod.Status.Conditions { if c.Type == PodReady && c.Status == ConditionTrue { return true } } return false } </ins>

I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil


Question: }, }, { <ins> name: "pod cannot be scheduled as all nodes don't have label 'rack'", pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "rack", v1.DoNotSchedule, st.MakeLabelSelector().Exists("foo").Obj(), ).Obj(), nodes: []*v1.Node{ st.MakeNode().Name("node-a").Label("zone", "zone1").Label("node", "node-a").Obj(), st.MakeNode().Name("node-x").Label("zone", "zone2").Label("node", "node-x").Obj(), }, wantStatusCode: map[string]framework.Code{ "node-a": framework.UnschedulableAndUnresolvable, "node-x": framework.UnschedulableAndUnresolvable, }, }, { </ins> name: "pods spread across nodes as 2/1/0/3, only node-x fits", pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "node", v1.DoNotSchedule, st.MakeLabelSelector().Exists("foo").Obj(),

What happened: I was testing out the pod topology spread functionality in a local k8s cluster. I noticed that when I set the constraint to be pods are still successfully scheduled. What you expected to happen: Reading the documentation on , I expected pods not to be scheduled since the node should be "bypassed due to the absence of label". Did I miss something here? How to reproduce it (as minimally and precisely as possible): Create a pod with topologySpreadConstraints[0].topologyKey that does not match to any node labels, and set to . Anything else we need to know?: Thank you Environment: Kubernetes version (use ):Cloud provider or hardware configuration: It's a kind cluster created with image . 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. </details
/sig scheduling
This sounds like a bug, I will look into it. /assign


Question: assert.Contains(t, err.Error(), "unknown group version field") } <ins> func TestParsePolicyWithUnknownField(t *testing.T) { f, err := writePolicy(t, policyWithUnknownField) require.NoError(t, err) defer os.Remove(f) _, err = LoadPolicyFromFile(f) require.NoError(t, err) } </ins> func TestPolicyCntCheck(t *testing.T) { var testCases = []struct { caseName, policy string

Currently the [audit policy decoder][1] silently drops unknown fields. For backwards compatibility, we probably cannot fail on unknown fields, but it would be good to at least log a warning when they're encountered. [1]: /sig api-machinery
/triage accepted
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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
I'm not familiar with apiserver, but this seems like a simple one. /assign
How can we find unknown fields in the yaml file? Currently I'm think of converting both the yaml file and the decoded Policy struct to two map[string]interface{}, and compare both map to find out which keys are in the yaml file but not in the decoded struct, is there any better solution?
Courtesy on slack:


Question: // Set up a wait for the first item's readyAt (if one exists) nextReadyAt := never if waitingForQueue.Len() > 0 { <ins> if nextReadyAtTimer != nil { nextReadyAtTimer.Stop() } </ins> entry := waitingForQueue.Peek().(*waitFor) <del> nextReadyAt = q.clock.After(entry.readyAt.Sub(now)) </del> <ins> nextReadyAtTimer = q.clock.NewTimer(entry.readyAt.Sub(now)) nextReadyAt = nextReadyAtTimer.C() </ins> } select {

Hi, We are experiencing a memory leak in our operator and it seems to be caused by some Timers: ! See here the original issue: After some investigations I found out that the can create a lot of timers (at least ) if the queue is not empty : The problem here is that if the event in the queue is to expire in a "far" future the previous timers will pile up and the memory will be reclaimed too late. Could someone confirm this scenario ? A fix would be to create some with and close them when they are not needed (e.g. is called) or superseded by a most recent one. Happy to discuss the issue and contribute if needed.
thanks for the report, moved to the main repo for better visibility /sig api-machinery
yes, using NewTimer would be better here
thanks for your feedback, could you assign me to this issue ? I will try to provide a fix.
Thanks, I have opened a PR:


Question: # $5: pod name, which should be either etcd or etcd-events function prepare-etcd-manifest { local host_name=${ETCD_HOSTNAME:-$(hostname -s)} <del> local -r host_ip=$(python3 -c "import socket;print(socket.gethostbyname("${host_name}"))") </del> <ins> local -r host_ip=$(${PYTHON} -c "import socket;print(socket.gethostbyname("${host_name}"))") </ins> local etcd_cluster="" local cluster_state="new" local etcd_protocol="http"

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gce-device-plugin-gpu Cluster up Apr 23 8:30PM PDT Taken from: From a , there are supposed to be three worker/minion nodes set up as well. Started failing after -- so maybe related to ? /cc /sig testing More examples of failing runs: /priority critical-urgent (this is a job on the release/master-blocking board)
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
It uses image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu as node image kubekins-e2e image is built from Base image is bootstrap image is built from with debian:buster and install python3.
The node image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu has no python3. We need to upgrade it.
Thanks for catching this and sending revert. Separately, we should definitely upgrade that image, cos-69 is super old and not supported anymore: /cc regarding GPU image


Question: - Name: cpu Weight: 1 `), <del> wantErr: `decoding .profiles[0].pluginConfig[0]: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.resources[0].Name", unknown field "scoringStrategy.resources[0].Weight"`, </del> <ins> wantErr: `strict decoding error: decoding .profiles[0].pluginConfig[0]: strict decoding error: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.resources[0].Name", unknown field "scoringStrategy.resources[0].Weight"`, </ins> }, { name: "out-of-tree plugin args",

With the addition of server side validation in 1.23, it is now possible for a call to successfully decode it’s data and return a non-nil error when there are strict decoding errors (e.g. duplicate/unknown fields). This means that callers of can distinguish between fatal errors (that cause decoding to fail) and strict decoding errors (that still allow the decode to succeed) by inspecting the target object (to see if it was successfully decoded into) and the error itself (to see if it is a ) With the NestedObjectDecoder however, it only returns an error from giving no indication whether a strict decoding error it has returned comes from an internal decode step that short circuited (by not accounting for strict decoding errors) or actually did successfully decode, but also encountered strict decoding errors. We propose taking a few actions to minimize the possibility of erroneous short-circuiting from Document how all nested decoders should only return strict decoding errors if all decoding is successful or return only non-strict decoding (ie. fatal errors). Document this for all known in-tree and out-of-tree . Update in-tree nested decoders to do the above mentioned behavior (which is just the kube-scheduler) Long-term solutions to better guarantee that no erroneous short-circuiting is taking place could include deprecating the current interface in favor of one that returns both the target object that was decoded into along with an error return a special error type specific to indicating that all internal decoding was successful.
/sig api-machinery
/triage accepted


Question: } // Check that ID list is correct. <del> ids := store.Contains() </del> <ins> ids := store.ContainedIDs() </ins> if !ids.HasAll("a", "c", "e") { t.Errorf("missing items") }

The client/cache interface has a method which is supposed to return a of the IDs in a store. This is a bit misleading and should probably be renamed to 'Contents' or 'ContainedIDs'.
Thoughts
I tend to agree. contains to me should always return a bool and take an input key. Sent from my iPhone
Yeah, I agree, both of the suggested names would be an improvement.


Question: return nil } <ins> func getSCSIControllersOfType(vmDevices object.VirtualDeviceList, scsiType string) []*types.VirtualController { // get virtual scsi controllers of passed argument type var scsiControllers []*types.VirtualController for _, device := range vmDevices { devType := vmDevices.Type(device) if devType == scsiType { if c, ok := device.(types.BaseVirtualController); ok { scsiControllers = append(scsiControllers, c.GetVirtualController()) } } } return scsiControllers } func getSCSIControllers(vmDevices object.VirtualDeviceList) []*types.VirtualController { // get all virtual scsi controllers var scsiControllers []*types.VirtualController for _, device := range vmDevices { devType := vmDevices.Type(device) switch devType { case SCSIControllerType, LSILogicControllerType, BusLogicControllerType, PVSCSIControllerType, LSILogicSASControllerType: if c, ok := device.(types.BaseVirtualController); ok { scsiControllers = append(scsiControllers, c.GetVirtualController()) } } } return scsiControllers } func getAvailableSCSIController(scsiControllers []*types.VirtualController) *types.VirtualController { // get SCSI controller which has space for adding more devices for _, controller := range scsiControllers { if len(controller.Device) < SCSIControllerDeviceLimit { return controller } } return nil } </ins> func getVirtualDiskUUID(newDevice types.BaseVirtualDevice) (string, error) { vd := newDevice.GetVirtualDevice()

vSphere cloud provider volume plugin attach disk limits the number of volumes because of two issues: new SCSI controller is only created when one does not exist. A new controller should be when required and limit not reached. disk will fail when attaching disk to slot 7 on controller. Slot 7 on SCSI controller is reserved and therefore should be skipped. This issue has been brought up in Govmomi library .


Question: func TestCalculateScaleUpLimitWithScalingRules(t *testing.T) { policy := autoscalingv2.MinChangePolicySelect <del> calculated := calculateScaleUpLimitWithScalingRules(1, []timestampedScaleEvent{}, &autoscalingv2.HPAScalingRules{ </del> <ins> calculated := calculateScaleUpLimitWithScalingRules(1, []timestampedScaleEvent{}, []timestampedScaleEvent{}, &autoscalingv2.HPAScalingRules{ </ins> StabilizationWindowSeconds: utilpointer.Int32Ptr(300), SelectPolicy:               &policy, Policies: []autoscalingv2.HPAScalingPolicy{

We created an hpa as following: Then started a deployment with 4 replicas and made the CPU utilization about 10%, which proposed to double the replicas, and it did work: Then we changed the CPU utilization to about 1%, which would trigger scaling down and would kill 2 pods only for scaleDown behavior: Then changed the CPU utilization to about 20%, which would trigger scaling up: It did scale up, and for our expectation, it should be scaled to 620/5=24 but would be limited by scaleUp behavior as 4(1+300%)=16, but in fact, it was just scaled up to 8 It would be scaled up to 16 in last scaling actions Start an hpa with a scaleUp behavior which has little long period and a little great Percent value, then start a deployment with a container whose CPU utilization could be controlled easily. Change the CPU utilization to make it scale up within limit, scale down a little, and scale up again without limit. I think it is caused by , this function seems that it just considered about scaleUp event history when calculate scaleUp limit (so does calculate scaleDown limit). I think it is a bit unreasonable. Does this action match the design? Or it does be a bug? <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig autoscaling
From what I understand, we observed the following behaviour: , there are pods. The HPA scales up new pods, so we have in total. , pods are scaled down, so we have in total. HPA calculates the desired Replicas with . Since all scaling events happened within the policies , the policy value of kicks in and should allow scaling up to . But it only scaled to .

I think that there is a bug in the following code: See the comments in the following snippets for an explanation: With a of 2, the is as follows: I will think of a possible solution to the problem and would like to contribute once I've made some progress on that :)
In fact, I knew this was caused by the calculating method of "getReplicasChangePerPeriod" and mentioned it in the "Anything else we need to know" of this issue. What I wonder now is that if it is an expected action or it is just a bug. If it quite is a bug, I hope I could contribute as well.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: // The Kubelet will look in this directory for an init configuration. // The path may be absolute or relative; relative paths are under the Kubelet's current working directory. // Omit this flag to use the combination of built-in default configuration values and flags. <del> // To use this flag, the DynamicKubeletConfig feature gate must be enabled. </del> <ins> // To use this flag, the KubeletConfigFile feature gate must be enabled. </ins> InitConfigDir flag.StringFlag // EXPERIMENTAL FLAGS

See:
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
For some reason GitHub didn't close this automatically when the referencing PR merged.


Question: return nil } <del> func (o *VersionOptions) Run() error { </del> <ins> // Run executes version command func (o *Options) Run() error { </ins> var ( serverVersion *apimachineryversion.Info serverErr     error

Anyone itching to understand the code and try fixing things in Kubernetes, please help fixing the lint failures Step 1: Remove one or two packages (related packages) from the list in - (note: do not change generated files, the name of defaulting functions, or the name of conversion functions... packages failing linting due to issues in those files will need to be left alone) Step 2: Run and look at the logged errors Step 3: Fix the code to ensure that runs cleanly. Step 4: Run and to make sure we fix any problems with gofmt or bazel. Step 5: File a PR with the change Step 6: Go to step :) Please use the tracking spreadsheet For everyone who is going to contribute, please append the packages you picked at the end. For existing contributor, please make sure this list is update to date
/sig architecture /sig testing
Hey, I would like to resolve this issue. Could you assign it to me ?
there are a lot of packages so there will be many people working on this. Also we cannot assign issue to folks who are not in the github org for kubernetes. please feel free to pick up a few packages like i mentioned and file a PR. Make sure you link back to this issue, so folks can see which packages you filed PR for.
OK. I see. I will firstly pick up the package called to fix.
Hi dims. Should i submit my PR before i remove one or two packages (related packages) from the list in - Or I first remove the package from list, then I fix the issue and submit a PR?
in your PR, you will have both the fixes to packages and some lines removed from /.golint_failures
When I run , I found some errors as below: I found that there is a go file in But there is still a error.
Say your GOPATH looks like this Your kubernetes directory should be () cd to and then run from that directory.
Is it necessary to obey all rules in golint? Rules in golint are set in stone. Maybe using gometalinter to ignore some specific errors is better?
I revise some erros about golint in some packages. Please review it.
which errors would you like to ignore?

if you can open a new issue with the list of errors to ignore (and proposing gometalinter), we can get some opinions there from others in the community.
Let me take the kubectl cmd part...
Can someone please review and let me know if I am doing it right?
I ll work on all the packages related to
we get 800-ish pkgs left to fix. my concern is that if we fix them package by package, then such pulls will be flooding the repo. can't we possibly make it in larger pulls? the larger the better?
+1 to slightly larger pulls with related packages. if allow too large then the reviewers will not be able to do a thorough review. we should spread the load among multiple reviewers. (if we allow a really large pull, we will end up with top level reviewers who will face the burden and the PR(s) will just stagnate)
oh good point. we could put one pkg's change into one commit, and merge all changes under one area into one pull so that it wont spread the load. wdyt? for each pull, we can have hundred-ish lines of change. but it will still be 30~50 pulls i guess? good news is that we can take our time to deal with it, at least before 1.12
sounds great! please feel free to help make it happen :) (by suggesting groups of packages that kinda go together)
I'm looking at fixing pkg/proxy, and I think I see what was talking about ignoring some rules. proxy.ProxyProvider is being suggested because golint is saying that it stutters. In that example, I think it's okay renaming it to proxy.Provider, but I could see an example where you would want to keep the stutter if the package that it's declared in uses it heavily.
sure thing, feel free to propose a PR for switching to gometalinter independently of other patches. We can work through that there.
I sent the pull request to fix pkg/volume/aws_ebs
I've fixed a few of these, but get the following error when I try to run : Are there any instructions on what I need to setup in order to resolve this?

you can find this file in
I have raised a PR to fix golint errors in pkg/api
I have fixed some pkgs under /pkg/kubelet pkg/kubelet/images pkg/kubelet/kuberuntime pkg/kubelet/leaky pkg/kubelet/pleg
I submitted a pull request for golint errors in pkg/security/ edit: I can work on picking up pkg/controller/bootstrap through pkg/controller/namespace/... (114-129)
fix golint errors in package cmd/kubeadm/app, since the codes under cmd/kubeadm/app/apis/kubeadm/v1alpha2 and cmd/kubeadm/app/apis/kubeadm/v1alpha3 are auto-generated, i keep them untouched.
I am working on some packages under pkg/kubelet, anyone interested in this plz leave messages for me :)
fix golint for pkg/util/dbus pkg/util/labels pkg/util/node pkg/util/strings pkg/util/workqueue/prometheus
PR fixes golint errors in pkg/routes,pkg/securitycontext, pkg/serviceaccount
PR fixes golint in pkg/probe
should we have a checklist as part of the issue summary saying what is in progress and what is done? Since this issue is getting long, this will make new contributors to pick up issues easier.
Great idea!, want to throw a google doc with a check-list so it's easy for participants to organize themselves? (please!) If it is the issue summary then one of us with privileges will be a bottle neck.
Created a with all the package that have on going PRs. Maybe you can add this to the summary. For everyone who is going to contribute, please append the packages you picked at the end. For existing contributor, please make sure this list is update to date
Thanks updated the spread sheet
Raised PR to fix golint issues in: pkg/controller/clusterroleaggregation pkg/controller/cronjob pkg/controller/daemon pkg/controller/deployment pkg/controller/deployment/util pkg/controller/disruption pkg/controller/endpoint
This issue is close in accident by . could you reopen it?
/reopen
Reopening 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
I found a problem trying to fix golint messages for .

Golint complaints on 's function because of the snake case. When I try to fix it, fails because it is being used in a code generated file. If I clean generated files, tests pass, but the generated file is not invoking it anymore. I failed to find the generator definition using this so I could change the hook to just . Also I'm not sure if this is wanted. I also found other packages in also probably affected by this. I read somewhere about replacing golint with gometalinter, which would allow to define directives in code to omit certain rules. I would consider to have a second exclusion file for golint with these cases, to be updated if move to gometalinter is finally done. This would make this issue completion more feasible. Meanwhile, I'll move onto fixing golint messages for other packages, until this discussion gets cleared.
I also found a problem fixing . A test fails because the directory is marked as readonly (see tests @ Shall we also ignore this directory for this issue?
Is this issue still relevant because hack/verify- is giving me no errors.
the failures are still present in there are details in the first message on how to claim + solve issues :)
Sorry I misunderstood the issue
I'm working on this package:
pkg/apis/admission/v1beta1 pkg/apis/authentication/v1beta1 pkg/apis/authorization/v1beta1 pkg/apis/coordination/v1 pkg/apis/coordination/v1beta1 pkg/apis/imagepolicy/v1alpha1 pkg/apis/scheduling/v1alpha1 pkg/apis/scheduling/v1beta1 pkg/apis/settings/v1alpha1 pkg/apis/storage/v1alpha1
pkg/cloudprovider/providers/vsphere/vclib pkg/kubelet/apis/deviceplugin/v1alpha pkg/kubelet/apis/pluginregistration/v1alpha1 pkg/kubelet/apis/pluginregistration/v1beta1
:
I'm looking at the pkg/registry/*, all those which are left. I expect to give an update on what all is fixed in the next 24-48 hours.
hi there is a google sheet that is a bit outdated, maybe you can update that?
hi I seem to only have view access for the sheet. Can't edit.
I fixed the permission.

Please try it again
pkg/apis/authentication pkg/apis/coordination pkg/apis/events pkg/apis/imagepolicy pkg/apis/settings
hi I think this issue was closed prematurely by (using fixes #issue in commit)
I'll put in a PR shortly for the package
Looking at next
hi thanks! there is a spreadsheet here that tracks the progress on fixing these issues, consider adding the packages you're work on there so we can keep everything organized :+1:
Starting on now
I did indeed see the Google Sheet link (thank you and to take it a little further
test/e2e
test/e2e_node/builder
pkg/registry/admissionregistration/mutatingwebhookconfiguration/storage pkg/registry/admissionregistration/rest pkg/registry/admissionregistration/validatingwebhookconfiguration/storage pkg/registry/apps/daemonset/storage
Hi. I opened a PR - Please review.
Working on Will open a PR soon.
Starting on and should have a PR soon
I keep getting this golint verify error on and was wondering if others saw it: But when I that package to the golint failures in my PR, my reviewer said it isn't necessary? What does that mean? What did I miss? Should I use a different kind of verify? cf:
looks like the disconnect is because that problem does not show up in the version of we use in the CI. please see
Still confused: is that not the golint version I ran? it installs from vendor and uses that I think?
i installed from and i still don't see the problem, can you please check what version of golint you have?
I'm confused why I wouldn't be using the vendored version? how would that get out of sync?
/me looking
Note: I am reserving for a KubeCon Contributor Workshop demonstration. It is noted in the spreadsheet.
I think may not be ideal cause there's a lot of auto generated files there. What do you think about reserving instead for the KubeCON Contributor Workshop?
pkg/apis/scheduling pkg/apis/storage/util pkg/apis/storage/v1beta1/util pkg/apis/storage/v1/util
/priority backlog
Hi I am a new contributor here, I'd like to contribute and make changes to the following file/s. I have marked it as WIP in the Google Sheet. Can someone let me know if I have to do anything else before I start working on this PR?

Umm so there's an issue where Golint tells that underscore shouldn't be allowed. Here's a log of the go-lint warnings:
Thanks The following should not be modified, as they are designed like this for code generation.
I'd like to pick a package and do my first PR, is there a list of packages to be done? Or should I correlate with this issue thread? Thanks in advance!
please see step 1 () please scan other PRs linked to this issue as well just in case.
Will do. Thank you. On Thu, Oct 3, 2019, 7:25 AM Davanum Srinivas <:
Hi there, I'm looking for a good first issue. I'll start taking a look at if that's ok? There doesn't seem to be anyone currently tracked as looking at it in the attached spreadsheet.
I've found a few others I'm actively looking at, you won't get any argument from me. On Sat, Oct 12, 2019, 10:38 AM Pamela Kelly <:
I am working on the iptables pkg. Updated in the google docs
/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
/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
I have problem running in step 2 $ hack/verify- what should I do?
PTAL for my pr to this issue, thx
you can move kubernetes directory to and re-run this script.
I'd like to take Can we fix linter issues for generated files? Or we should skip packages with zz_generated?
There're 2 lint errors that affects 292/507 packages, meaning it's not possible to cleanup the entire file without solving it: default pattern of Kubectl is the usage of [cmd]Options for initial options structs and it raises: /apis/{custommetrics,externalmetrics} for example raises the underscore error, but It's probably not worth to break backward compatibility renaming these folder for lint error fix: Any advice on these?

/reopen hm, cannot reopen this issue, it was closed by mistake
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
/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
I am sure this is all not fixed. Am I missing something? ./hack/verify- installing golint from vendor Congratulations! All Go source files have been linted.
you need to remove package from first.
/remove-sig testing SIG testing doesn't own code failing lints, we own the linter. :upsidedownface:
Hello, is this still a relevent issue ? I would like to work upon
I have fixed
Hi Folks, Some of the golint fixes, require us to change the exposed function's name, in simple words, "change API". I was not sure, if that is welcomed and what is the process.
Heres what Im getting after going over the following steps as mentioned by Say your GOPATH looks like this GOPATH=/Users/dims/go Your kubernetes directory should be ($) cd to and then run hack/verify- from that directory. I get the following output - installing golint Congratulations! All Go source files have been linted. Im not really sure what I am doing wrong. Any help is appreciated!
I think I understand. I misunderstood the steps around .golint_failures. The first step is to remove the pkg that we are targeting from this file and then run the My mistake was to assume that the packages in the file need to be removed after we are done cleaning the golint errors.
Can someone please review and let me know if I've done this right?
After a couple years of seeing changes spawned from this issue, I don't think this is a good use of contributors' or reviewers' time.

golint is very opinionated about: exported type and function names, leading to PRs attempting to change exported things people use downstream missing documentation on interface implementation functions, which leads to not-very-useful copy/paste of interface godoc the govet and staticcheck verify jobs are much more useful since they catch correctness issues, but I would recommend closing this issue and dropping the golint checks from CI golint doc itself discourages from using its output in an automated enforced way: from
i guess one can say gofmt is opinionated too, but something good about Golang is that it comes with an opinion and a set of standard tools. for API documentation at least we found inconsistencies on how most exported API items are documented: golint can help with that, but if there are no "pragmas" to avoid breaking changes and given we have codegen generating non-compliant names enabling golint on API packages is sort of blocked in Kubernetes. for non-API, non-library, non-public code, i think being inconsistent is mostly OK. no preference on my side. shrug
true, but code formatting has the benefits of mostly eliminating meaningless diffs in PRs due to code movement/whitespace/etc if there are specific packages (like API packages) we lack documentation on, adding checks specifically for that could make sense exactly, I don't think golint is the right tool for making sure we have API docs
golint itself doesn't have these and the go project is against this sort of comment AIUI, however golangci-lint does have them. I think there are plenty of other static analysis lints we should use instead, beyond just staticcheck and vet there is e.g.
btw, if we remove golint can we see e.g. all-caps constants or functions with underscores dodging review? perhaps we should add golangci-lint soon after:
Completely agree there are better places to spend review bandwidth. I was curious to see what the effort looked like. There have been 890 commits that touched over the past 3+ years !
/remove-help /remove-good-first-issue
Overall agree on the bandwidth. Also note that it was a good first issue with very low bar to get them in the repo. May be we need to find a similar low bar, but high value good first issue.

UT's come to mind, are there other things we curate for new contributors ?
Do we have an alternative way of enforcing that new exported code (not necessarily API fields) has at least some minimum documentation? As a reviewer, I ask contributors to add meaningful comments. But reality is that I sometimes stumble into old code that doesn't have documentation because we didn't have golint at some point. I agree that fix-golint PRs just add burden to reviewers. But, before removing the lint check, can we wait and see if it's enough to discourage people from sending more PRs like this? Additionally, we can encourage reviewers to just close PRs that only fix golint issues.
+1 for adding burden to reviewers. However, as a new contributor, I think this a very good opportunity for new contributors to study the code base and submit their first PR. In my opinion, I think this issue would be able to attract more new contributors, get familiar with the code base, and get familiar with the git workflow.
thanks everyone for getting us this far. We essentially gave up on the existing structure/system for golint: At some point we can look at adding golangci-lint, there's a WIP in progress in /close
Closing this issue. <detailsIn response to : thanks everyone for getting us this far. We essentially gave up on the existing structure/system for golint: 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: for attempts := 0; attempts < 4; attempts++ { outputBytes, err = exec.Command("gcloud", "compute", "addresses", "create", name, "--project", TestContext.CloudConfig.ProjectID, <del> "--region", region, "-q").CombinedOutput() </del> <ins> "--region", region, "-q", "--format=yaml").CombinedOutput() </ins> if err == nil { break }

5 tests failed, 6 jobs failed, 151 builds failed. Failure stats cover 1 day time range '2 Jun 2017 20:57 UTC' to '3 Jun 2017 20:57 UTC'. <details<summaryRationale for assignments:</summary </details<br
/unassign I am probably not the right owner for these tests. Leaving this to to triage it.
This seems pretty likely a quota issue. Many of them started after the cleanuped the old gce resources. Probably some tests are leaking resources. Though it doesn't occur on other CIs like . I will dig into it a bit more.
The root cause is ~2 years old from We are parsing human readable gcloud output, which recently changed. Additionally, when we fail to create the LB we leak the static IP address. It's failing on GKE but not GCE because GKE uses a pre-release version of gcloud as a canary.
/priority failing-test
/reopen ci-kubernetes-e2e-gci-gke-slow-release-1.5 and ci-kubernetes-e2e-gke-slow-release-1.5 will continue failing until we cherry pick the fix. Reopen for now.
Forgot to update: ci-kubernetes-e2e-gci-gke-slow starts passing after was merged.
Can you cherrypick to both 1.5 and 1.6 branch? But this issue is not 1.7 blocking issue anymore.
Sure, working on it.
Sent cherry picks: release-1.6: release-1.5: release-1.4: Cherrypicking the fix into 1.4 as well because we also have gce-slow-1.4 and gci-slow-1.4 CIs running.
remove the milestone, this is not a 1.7 issue
Since all issues listed here are addressed separately. Close this one.


Question: expectedNodeCondition := v1.NodeDiskPressure expectedStarvedResource := v1.ResourceEphemeralStorage pressureTimeout := 10 * time.Minute <ins> highPriorityClassName := f.BaseName + "-high-priority" highPriority := int32(999999999) BeforeEach(func() { _, err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Create(&schedulerapi.PriorityClass{ObjectMeta: metav1.ObjectMeta{Name: highPriorityClassName}, Value: highPriority}) Expect(err == nil || errors.IsAlreadyExists(err)).To(BeTrue()) }) AfterEach(func() { err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Delete(highPriorityClassName, &metav1.DeleteOptions{}) Expect(err).NotTo(HaveOccurred()) }) </ins> Context(fmt.Sprintf(testContextFmt, expectedNodeCondition), func() { tempSetCurrentKubeletConfig(f, func(initialConfig *kubeletconfig.KubeletConfiguration) { initialConfig.FeatureGates[string(features.PodPriority)] = true

https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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 . 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: action := testing.ActionImpl{} action.Verb = "get" action.Resource = schema.GroupVersionResource{Resource: "version"} <del> c.Invokes(action, nil) </del> <ins> _, err := c.Invokes(action, nil) if err != nil { return nil, err } </ins> if c.FakedServerVersion != nil { return c.FakedServerVersion, nil

<!-- 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: I was trying to write a test in a service I'm working on to catch if an error returns from . When I overrode the result of the fake client with a reactor to return an error I did not get the error back. What you expected to happen: If the reactor is set to return an error, it should come back. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This only happens with the fake. Environment: Kubernetes version (use ): 1.14 Cloud provider or hardware configuration: any OS (e.g: ): any Kernel (e.g. ): any Install tools: any Network plugin and version (if this is a network-related bug): n/a Others:
/sig testing
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
Let's take a look at this /priority important-longterm /sig api-machinery /remove-sig testing /remove-lifecycle rotten
Is there any progress?
I submited a PR to fix this issue. PTAL .
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 . 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
^^^ would it be possible to reconsider this PR? I ran into the same issue today.
this hasn't been fixed and we recently ran into this issue. Can we /reopen? Happy to bring up to date.
/reopen still relevant as above
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
/remove-lifecycle rotten /triage accepted
/assign


Question: ObjectMeta: metav1.ObjectMeta{Name: saRolePrefix + "ephemeral-volume-controller"}, Rules: []rbacv1.PolicyRule{ rbacv1helpers.NewRule("get", "list", "watch").Groups(legacyGroup).Resources("pods").RuleOrDie(), <ins> rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("pods/finalizers").RuleOrDie(), </ins> rbacv1helpers.NewRule("get", "list", "watch", "create").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), eventsRule(), },

This test fails when OwnerReferencesPermissionEnforcement admission plugin is enabled: After the test creates a pod with an ephemeral volume, ephemeral volume controller in kube-controller-manager fails to create a PVC for it: The controller must have permissions to to be allowed to set with to Pods. The test passes. With : ENABLEADMISSIONPLUGINS="NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,Priority,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,OwnerReferencesPermissionEnforcement" ALLOWPRIVILEGED=true LOGLEVEL=4 hack/local-up- Kubernetes version (use ): 1.21.0 & today's master
/sig storage /triage accepted /priority important-soon


Question: # Golang - name: "golang: upstream version" <del> version: 1.23rc2 </del> <ins> version: 1.22.5 </ins> refPaths: - path: .go-version - path: build/build-image/cross/VERSION <del> # TODO: remove this when whe have the go1.23 released and not the rc. # - path: staging/publishing/rules.yaml #   match: 'default-go-version: d+.d+(alpha|beta|rc)?.?(d+)?' </del> <ins> - path: staging/publishing/rules.yaml match: 'default-go-version: d+.d+(alpha|beta|rc)?.?(d+)?' </ins> - path: test/images/Makefile match: GOLANG_VERSION=d+.d+(alpha|beta|rc)?.?d+

sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)


Question: exit 1 fi <ins> version=$(etcd -version | cut -d " " -f 3) if [[ "${version}" < "2.0.0" ]]; then kube::log::usage "etcd version 2.0.0 or greater required." exit 1 fi </ins> # Start etcd ETCD_DIR=$(mktemp -d -t test-etcd.XXXXXX) <del> etcd -name test -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null & </del> <ins> kube::log::usage "etcd -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null" etcd -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null & </ins> ETCD_PID=$! <del> kube::util::wait_for_url "http://${host}:${port}/v2/keys/" "etcd: " </del> <ins> echo "Waiting for etcd to come up." while true; do if curl -L http://127.0.0.1:4001/v2/keys/test -XPUT -d value="test"; then break fi done kube::util::wait_for_url "http://${host}:${port}/v2/keys/test" "etcd: " </ins> } kube::etcd::cleanup() {

writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:


Question: path: /run/xtables.lock ` <del> KubeDNSVersion = "1.14.2" </del> <ins> KubeDNSVersion = "1.14.3" </ins> KubeDNSDeployment = `

A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.


Question: [Service] EnvironmentFile=/etc/sysconfig/kubelet ExecStart=/usr/local/bin/kubelet "$DAEMON_ARGS" <del> Restart=on-failure </del> <ins> Restart=always </ins> [Install] WantedBy=multi-user.target  No newline at end of file

Self-assigning as I work out a reliable fix.
cc
Running into a few issues. On GCE, did you guys block somewhere to wait for etcd to be running before reporting success on kube-up?
No, except there is a race between addson services, dns and etcd container. We introduced a retry logic on those services.
I assume pulling the image is just so fast that you don't run into e2e errors, it looks like you guys block on wait-for-minions that uses glcloud, so I guess when minions are reported in etcd, then you know you are good...


Question: return fmt.Errorf("invalid image pull policy: %s", o.PullPolicy) } <ins> // Target if len(o.Target) > 0 && len(o.CopyTo) > 0 { return fmt.Errorf("--target is incompatible with --copy-to. Use --share-processes instead.") } </ins> // TTY if o.TTY && !o.Interactive { return fmt.Errorf("-i/--stdin is required for containers with -t/--tty=true")

This issue tracks implementing node debugging with privileged containers for , as described in the This feature allows administrators to start a privileged container on a node in host namespaces rather than having to SSH to the node. For example: /kind feature /sig cli
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale


Question: kube-master-url kube-reserved kubeadm-path <ins> kubeadm-cmd-skip </ins> kubecfg-file kubectl-path kubelet-address

go test ./cmd/kubeadm/... fails with: it appears to be following a "RunCmd" pattern used by e2e tests, but unit tests should not require built binaries
can work on this
has a long discussion as to why this is. These tests only get run when gets run, which will produce the needed binary and pass it in as arg. For more information, authored this and should be able to provide more details.
Yup, the target explicitly ignores these tests: and like said, runs this script as part of its target:
then the test should have build tags to exclude it from a regular run of the package
or up for fixing that?
I thought build tags only works on the OS level or if you it would ignore it completely? Wouldnt break the command as well?
I'd also tolerate skipping the test if the built binary doesn't exist
I think that is a great solution. I think in I had initially suggested something like that. If everyone is ok with that, I will go ahead and make that change.
Sounds good, make that change and we'll see how it turns out. I'd really want these tests start working, so +1


Question: server.ListenAndServeKubeletReadOnlyServer(kl, kl.resourceAnalyzer, address, port, kl.containerRuntime) } <ins> // Delete the eligible dead container instances in a pod. Depending on the configuration, the latest dead containers may be kept around. func (kl *Kubelet) cleanUpContainersInPod(podId types.UID, exitedContainerID string) { if podStatus, err := kl.podCache.Get(podId); err == nil { if status, ok := kl.statusManager.GetPodStatus(podId); ok { // If a pod is evicted, we can delete all the dead containers. kl.containerDeletor.deleteContainersInPod(exitedContainerID, podStatus, eviction.PodIsEvicted(status)) } } } </ins> // isSyncPodWorthy filters out events that are not worthy of pod syncing func isSyncPodWorthy(event *pleg.PodLifecycleEvent) bool { // ContatnerRemoved doesn't affect pod state

Kubelet evicts pods whenever there is memory or disk pressure. It marks the pods as to evict them. To help with reducing disk pressure, kubelet should delete all containers belonging to pods right away. This will result in loss of logs. In the future, we can copy out logs from dead containers before deleting them. Logs can be rotated separately from dead containers. IMO, this feature is required for disk usage based evictions to work reliably in kubelet.


Question: framework.ExpectEqual(successes, largeCompletions, "expected %d successful job pods, but got  %d", largeCompletions, successes) }) <del> ginkgo.It("should apply changes to a job status", func() { </del> <ins> /* Release: v1.24 Testname: Jobs, apply changes to status Description: Attempt to create a running Job which MUST succeed. Attempt to patch the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed */ framework.ConformanceIt("should apply changes to a job status", func() { </ins> ns := f.Namespace.Name jClient := f.ClientSet.BatchV1().Jobs(ns)

[x] Test PR : [x] Two weeks soak end date : 6 April 2022 [X] Test promotion PR : According to this APIsnoop query, there are still some remaining Job status endpoints which are untested. There are conformance tests for CronJob status endpoints already the existing as a template, a new for job test has been created. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: sctpPort    = -1 shellPath   = "/bin/sh" serverReady = &atomicBool{0} <ins> certFile    = "" privKeyFile = "" </ins> ) // CmdNetexec is used by agnhost Cobra. var CmdNetexec = &cobra.Command{ Use:   "netexec", <del> Short: "Creates HTTP, UDP, and (optionally) SCTP servers with various endpoints", Long: `Starts a HTTP server on given port with the following endpoints: </del> <ins> Short: "Creates HTTP(S), UDP, and (optionally) SCTP servers with various endpoints", Long: `Starts a HTTP(S) server on given port with the following endpoints: </ins> - /: Returns the request's timestamp. - /clientip: Returns the request's IP address.

<!-- Please only use this template for submitting enhancement requests --What would you like to be : The image used in E2E tests is used for testing a wide variety of OS-agnostic features. One of these is , which runs an HTTP server with various endpoints that can be used to validate things like request/response. It would be useful to allow for 's functionality to also support HTTPS so all of that logic can be tested for TLS-based traffic. Currently, can be run like: I'm proposing something along the lines of: The default certificate/private key being basically identical to what provides. Why is this needed: One use case is where the intent is to add HTTPS functionality to lifecycle hooks (postStart/preStop). There is currently no easy way to test this logic because the container which receives the HTTPS request (in this case, ) does not support HTTPS traffic.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig testing


Question: lb.opts.SubnetId = subnetID } <ins> floatingPool := getStringFromServiceAnnotation(apiService, ServiceAnnotationLoadBalancerFloatingNetworkId, lb.opts.FloatingNetworkId) glog.V(4).Infof("EnsureLoadBalancer using floatingPool: %v", floatingPool) var internalAnnotation bool internal := getStringFromServiceAnnotation(apiService, ServiceAnnotationLoadBalancerInternal, "true") switch internal { case "true": glog.V(4).Infof("Ensure an internal loadbalancer service.") internalAnnotation = true case "false": if len(floatingPool) != 0 { glog.V(4).Infof("Ensure an external loadbalancer service.") internalAnnotation = false } else { return nil, fmt.Errorf("floating-network-id or loadbalancer.openstack.org/floating-network-id should be specified when service.beta.kubernetes.io/openstack-internal-load-balancer is false") } default: return nil, fmt.Errorf("unknow service.beta.kubernetes.io/openstack-internal-load-balancer annotation: %v, specify "true" or "false".", internal) } </ins> ports := apiService.Spec.Ports if len(ports) > 1 { return nil, fmt.Errorf("multiple ports are not supported in openstack v1 load balancers")

Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently openstack cloud provider just support for specifying internal LoadBalancerIP. I think that is unreasonable, actually user just use a floating ip to access a LoadBalancer service. So it is necessary to spport for specifying external LoadBalancerIP. What you expected to happen: Support for specifying external LoadBalancerIP on openstack Anything else we need to know?: Currently LoadBalancerIP can be specified in service.Spec.LoadBalancerIP, we can add annotation to distinguish between internal and external.
/sig openstack /assign I'd like to work for it.