Question: echo "    echo 'Waiting for metadata MINION_IP_RANGE...'" echo "    sleep 3" echo "done" <ins> echo "" echo "# Remove docker artifacts on minion nodes" echo "iptables -t nat -F" echo "ifconfig docker0 down" echo "brctl delbr docker0" echo "" </ins> echo "EXTRA_DOCKER_OPTS='${EXTRA_DOCKER_OPTS}'" echo "ENABLE_DOCKER_REGISTRY_CACHE='${ENABLE_DOCKER_REGISTRY_CACHE:-false}'" grep -v "^#" "${KUBE_ROOT}/cluster/gce/templates/common.sh"

I suspect this is dues to the recent change to container VMs as the base image? ifconfig docker0 - exists but should not. iptables-save | grep docker - 4 docker rules that should not exist.
Is this still relevant?
was still a containervm turd the last time I checked. It's just not causing any harm.
Yeah, no harm, just ugly. , Zach Loafman wrote:
I think we should remove the docker0 from minion nodes, but do we still need this for master node? cc/
This is required by running etcd server as pod with flannel on gce nodes. Please sync your cluster with this fix.


Question: "failFSGroupOutOfRange": { pod:           failFSGroupPod, psp:           failFSGroupPSP, <del> expectedError: "999 is not an allowed group", </del> <ins> expectedError: "group 999 must be in the ranges: [{1 1}]", </ins> }, "failFSGroupEmpty": { pod:           defaultPod(),

Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help


Question: "models": { "v1.Binding": { "id": "v1.Binding", <del> "description": "Binding ties one object to another. For example, a pod is bound to a node by a scheduler.", </del> <ins> "description": "Binding ties one object to another; for example, a pod is bound to a node by a scheduler. Deprecated in 1.7, please use the bindings subresource of pods instead.", </ins> "required": [ "target" ],

Forked from We need to update the scheduler (ours and mesos) to use pods/binding instead of /binding and then we can delete /binding.
cc
This is about the top-level resource, not the subresource.
This is where mesos is using binding as top level resource: We need to change that to Resource("pods").Subresource("bindings")
/cc
If we turn this off in 1.2, will that be a problem for you?
Did we announce we were going to remove this API? Don't we need to have a process for taking it away?
Yes it would be problematic unless our scheduler was updated to use whatever was replacing it. AFAICT even the core scheduler is still using /bindings: , Clayton Coleman wrote:
Kicking this can down the road.
We should mark this deprecated.
According to , kube-mesos refactor will use HTTPExtender, so it's a not big issue to kube-mesos. But for k8s, I think scheduler is using API now ().
/assign
/close I'm going to close this; if any comments, please let me know.
We need to actually mark the endpoint deprecated so we can remove it.
OK, got that; need to deprecate it for other user. I think k8s can handle it to use .
, can you help to remove ? it's not related with Mesos anymore. I'll create a PR to deprecate .
Reopening since that PR just a deprecation warning. We still need to remove the API.
wow, agree. , would you help to remove milestone? We will not remove API in 1.7 or 1.8; but I'll trace that.
Done
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
18 still have.
21 still have the resource. Is anyone already working on it or is there a reason why the binding resource still get served?

not entirely sure if i'm right, but from my current assumption it seems that there isn't an implementation for the for pods (xref: ) and we still use the generic resource for pods (). The resource is deprecated since 1.7 but i don't see any further progress :thinking: () dump of an :
what is the progress with this issue? Is it a backlog item that is tracked by sig scheduling?
I'm not aware of this issue. We will put it into our sig meeting to discuss.
we went through this in today's scheduling meeting. We're ok with shifting v1.Binding to pod's subresource. Before acting on it, there are several factors we need to consider: impact to external integrators - either 3rd-party scheduler or scheduler plugins (using extension point). Follow the conventional API deprecation/removal guide/process to ensure a smooth migration. overall volume of efforts. In addition to scheduling efforts, are there any API Server side efforts that need to be tweaked as well? we need to get +1 from
Is there a summary of why moving this API is necessary given that is has been around for quite sometime now? Is it related to RBAC?
/binding is a v1 API, and as such, deletion is not permitted. It can be marked deprecated, and users pointed to pods/binding by documentation as the preferred method, but not removed.
It's more to pay the technical debt. Given the action "binding" is performed against pods, composing a pod/binding instead of v1.Binding makes more sense. Thanks for clarification we cannot remove v1 APIs.
ok, thanks for the clarification, so this is not enabling a new use case, only a cleanup.
Right, and due to the stable API compatibility guarantees, I don't think it's a cleanup we can do. /close
Closing this issue. <detailsIn response to : so this is not enabling a new use case, only a cleanup. 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
Sorry for the late comment on this but i was AFK for a longer time. I'm not sure if we missed something. Currently there is only the implementation.

via the the API endpoint exists but it refers to the only existing kind (could be checked via ): As there isn't a seperate implementation for IMO we should remove the deprecation warning as we don't have an alternative implementation for that in place. / WDYT?


Question: &api.Pod{ DesiredState: desiredState, CurrentState: api.PodState{ <ins> Host: "machine-2", }, }, api.PodTerminated, "no info, but bad machine", }, { &api.Pod{ DesiredState: desiredState, CurrentState: api.PodState{ </ins> Info: map[string]docker.Container{ "containerA": runningState, "containerB": runningState,

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


Question: }, "embedded-object": { "x-kubernetes-embedded-resource": true, <del> "x-kubernetes-preserve-unknown-fields": true, "type":"object" </del> <ins> "x-kubernetes-preserve-unknown-fields": true </ins> } }, "x-kubernetes-group-version-kind":[{"group":"bar.k8s.io","kind":"Foo","version":"v1"}]

What happened: I have CRD with a spec field of type and annotation . I want to store json data in this field which is actually a Grafana Dashboard json. When I try to create a CR of this type, I am getting validation error from json bytes. . In the json data . What you expected to happen: I expected no error since I set How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.17.0 Cloud provider or hardware configuration: kind OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig api-machinery /area custom-resources
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: I have CRD with a spec field of type and annotation . I want to store json data in this field which is actually a Grafana Dashboard json. Kubernetes version (use ): v1.17.0 Cloud provider or hardware configuration: kind OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig api-machinery /area custom-resouces Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc:
, you are able to create the CRD, which is also working for me. Are you able to create the CR for this CRD? Does the following command work for you?
Running the second command:
I think you have not read the issue clearly. The CRD creation is working fine. I am getting validation error when trying to create CR for this CRD.
I edited the previous comment with result for second command.
Thanks ! This is the issue I see. I expected no error since I set .
If you pass --validate=false, does it create successfully?
Yes, if I pass --validate=false, it creates successfully.
Then the issue is in client-side kubectl validation, and the server is behaving as expected
/cc for openapi validation
Yeah, we should probably make anything that has the accept anything.

I thought we already did so for types that are . Maybe this never landed actually, I could look it up.
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
That's probably not super hard to solve if someone wants to try.
A good way to start would be to solve all the TODOs in Or possibly, to address this bug specifically: This is the function that validates the "kind" (i.e. structures): When I initially wrote this code, we assumed that these type would never have additionalProperties. We probably need to change this condition since it's not really valid: and this one: We create the kind here: That function would have to be changed to save the "additionalProperties" type (if given) or the ability to have additionalProperties.
Actually, the problem also is that it doesn't know how to handle null. This one is a little tricky.
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
I think the publishing of the "object" type must be supressed for fields. We have similar cases already.

Touching kubectl is not very effective, or at least it takes multiple releases to makes its way through the ecosystem.
/assign


Question: // Enables kubelet to detect CSI volume condition and send the event of the abnormal volume to the corresponding pod that is using it. CSIVolumeHealth featuregate.Feature = "CSIVolumeHealth" <del> // owner: @enj // beta: v1.22 // ga: v1.24 // // Allows clients to request a duration for certificates issued via the Kubernetes CSR API. CSRDuration featuregate.Feature = "CSRDuration" </del> // owner: @adrianreber // kep: http://kep.k8s.io/2008 // alpha: v1.25

Remove the "CSRDuration" feature gate starting in Kube v1.26. PR proposes that the CertificateSigningRequest's Spec.ExpirationSeconds field be promoted to GA in v1.24. It was originally introduced as beta in v1.22 with a corresponding feature gate called "CSRDuration" to optionally disable it (see PR ). If PR is merged and included in v1.24, then in v1.26 the "CSRDuration" feature gate should be removed. See also where a member of SIG-auth asked me to create this issue.
/sig auth
/triage accepted /milestone v1.26
Is this task a ? I would like to be assign to it.
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
I'd like to work on this! /assign
Fixed it here:


Question: var _ volume.Deleter = &cinderVolumeDeleter{} func (r *cinderVolumeDeleter) GetPath() string { <del> name := cinderVolumePluginName return r.plugin.host.GetPodVolumeDir(r.podUID, kstrings.EscapeQualifiedNameForDisk(name), r.volName) </del> <ins> return getPath(r.podUID, r.volName, r.plugin.host) </ins> } func (r *cinderVolumeDeleter) Delete() error {

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: ) const ( <del> defaultZone = "" </del> <ins> defaultZone                   = "" networkInterfaceIP            = "instance/network-interfaces/%s/ip" networkInterfaceAccessConfigs = "instance/network-interfaces/%s/access-configs" networkInterfaceExternalIP    = "instance/network-interfaces/%s/access-configs/%s/external-ip" </ins> ) func newInstancesMetricContext(request, zone string) *metricContext {

What happened: when initializing a kubernetes cluster in Google Cloud manually (not using GKE), internal (and external if available/applicable) node IP is not populated in "kubectl get nodes" if the interface used to connect to the master and passed to kubelet does not correspond to the first network interface, nic0 on google cloud console UI. I cannot "kubectl edit node" and patch in the node IP information into the "addresses" field either. This issue does not occur when kubelet --node-ip=(ip of nic0). kubelet on all members of the cluster declare cloud-provider="gce". What you expected to happen: when kubelet is given a node-ip argument, it is checked against all nics of the google cloud instance and populated in node information even if a nic other than nic0 is used. Or at least I am allowed to override nodeIP somehow after the node is brought up. How to reproduce it (as minimally and precisely as possible): We have scripts that automate this "manual kubernetes" process, I will describe it as generally as I can but i can share chunks of the script as needed. Given two VPCs, initialize an instance for master, one nic on VPC1 initialize an instance for worker with two nics, one on VPC2, the other on VPC1. install required dependencies on both (apt-get docker-ce kubelet kubeadm kubectl ...) on master, mkdir -p /etc/default/kubelet; echo "KUBELETEXTRAARGS=--cloud-provider='gce' /etc/default/kubelet; kubeadm init on worker, mkdir -p /etc/default/kubelet; echo "KUBELETEXTRAARGS=--node-ip=(nic1 ip) --cloud-provider='gce' /etc/default/kubelet; kubeadm join wait a bit. kubectl get nodes -o wide, verify no internal IP or external IP information is populated for the worker journalctl -xef on worker to see something like ] Failed to set some node status fields: failed to get node address from cloud provider that matches ip: (nic1 ip) Anything else we need to know?: i'm guessing the problem stems from something like where we only check nic0 and return that, and then this bit here only loops through nic0's info, doesn't match, and then we return an error.

if the first bit returned an array of IPs instead of just a single set, that would probably fix this. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-04-08T17:30:47Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Google Cloud, all n1-standard-4 instances OS (e.g: ): NAME="Ubuntu" VERSION="18.04.4 LTS (Bionic Beaver)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 18.04.4 LTS" VERSIONID="18.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" VERSIONCODENAME=bionic UBUNTUCODENAME=bionic Kernel (e.g. ): Linux 5.0.0-1033-gcp -Ubuntu SMP Tue Mar 3 04:36:26 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: installed kubeadm kubelet docker and whatever else through apt-get Network plugin and version (if this is a network-related bug): Others:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider ? 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
w.r.t. NodeAddresses in We can keep calling Get for 1/ip, 2/ip, ... until err is non-nil. Is there a better way to find how many interfaces there are ?
i haven't used the gcloud go metadata client, but looping until error or hitting instance/network-interfaces directly for the interface indices available is probably about the same since NIC count is limited by VM tier anyways.


Question: * SSLv3, TLS alert, Client hello (1): ``` <del> This shows that the request to `https://104.197.5.247/api/v1beta3/redirect/namespaces/default/services/elasticsearch-logging` is redirected to `http://10.244.2.7:9200`. If we examine the pods on the cluster we can see that `http://10.244.2.7` is the address of a pod that is running the Elasticsearch service. </del> <ins> We can also run the `kubectl get pods` command to view a list of the pods on the cluster and verify that `http://10.244.2.7` is where the Elasticsearch service is running: </ins> ``` $ kubectl get pods POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                                                  LABELS                                                                      STATUS              CREATED

is out of date. Please update for the current location/contents of the file and v1beta3. Once is submitted we should also update the examples to show to to curl using bearer tokens instead of basic auth credentials.
We're working on scrubbing the docs and examples of references to v1beta1 () prior to deleting that API, so it would be good to have this in soon.
: let me know if you want to punt this back to me -- now that I have some clue again about how to access an cluster (assuming I can create a cluster!).
Punting back to you. Getting the auth credentials is accomplished via But I think you have a better idea how to curl with token auth than I do.


Question: verbs:     "get,watch,list", resources: "replicasets.extensions/scale", expectedRole: &rbac.Role{ <ins> TypeMeta: v1.TypeMeta{APIVersion: "rbac.authorization.k8s.io/v1", Kind: "Role"}, </ins> ObjectMeta: v1.ObjectMeta{ Name: roleName, },


Question: package keystone import ( <ins> "crypto/tls" </ins> "errors" <ins> "net/http" </ins> "strings" "github.com/golang/glog" "github.com/rackspace/gophercloud" "github.com/rackspace/gophercloud/openstack" "k8s.io/kubernetes/pkg/auth/user" <ins> certutil "k8s.io/kubernetes/pkg/util/cert" netutil "k8s.io/kubernetes/pkg/util/net" </ins> ) // KeystoneAuthenticator contacts openstack keystone to validate user's credentials passed in the request. // The keystone endpoint is passed during apiserver startup type KeystoneAuthenticator struct { <del> authURL string </del> <ins> authURL   string transport http.RoundTripper </ins> } // AuthenticatePassword checks the username, password via keystone call

Hi, I tried to integrate the keystone auth plugin (which would be perfect for my needs) into the cluster I'm currently setting up. However, I can't get the connection working since our keystone installation is currently only reachable over http As far as I can see in , there is no option to deactivate this check. I think this should be an optional parameter on startup, similar to defaulting to the check being activated.
I don't think we should enable username/password checking over http.
I agree that we are loosing a security layer here, but you can't guarantee you got the password from client over https, so it might be intercepted at this point anyways. More general, I think the proper way to authenticate to Kubernetes with the Keystone plugin using tokens since they will limited lifetime restricted on keystone only which is a big deal regarding keystone likely being bound to a LDAP and thus the password being valid for other services. So I don't want to check username/password directly. I'm just starting out with the Keystone plugin, so I want to point this out in general, if token auth is supported, the better. Couldn't try it in praxis for now since I can't get the auth URL running.
Assigning to to add a priority label.
Setting the priority low until we have a sense of how many users have this restriction (keystone only reachable over http).
I ran into this same issue with trying to deploy kubernetes with devstack in the same vm and wanted to test integration and do some development. I think there are a significant number of developers in this same boat. http is secure enough since it doesn't leave the developers vm and it isn't intended for production. The use case is the same as:
I'd vastly prefer allowing specifying the CA for the keystone server over allowing http auth calls carrying usernames and passwords
I don't disagree. :) But, I also think Kubernetes shouldn't handle the usernames/passwords at all. In http mode, sending a token is much less risky then a username/password since they expire relatively quickly. See this issue for details:
I agree tokens would be preferable, but I wouldn't expect credentials of any kind sent over http to remote servers
Agreed. No one in their right mind should be passing creds or bearer tokens over http over a network.

I'm just interested in being able to easily deploy a k8s in DevStack with a simple plugin, where that k8s is hooked into the deployed keystone so that we can start developing things in OpenStack that depend on k8s. This gives developers a smooth/easy experience to then focus on doing the development stuff and not have to mess with setting up a CA/k8s, which will prevent some of them from contributing to k8s/OpenStack. The idea is simple for developers, secure for operators. Totally separate use cases.
It should be as simple as telling k8s to trust the keystone cert as a CA (assuming the self-signed cert generated by keystone is correctly marked as a CA, which it should be, since it is signing for itself). I've seen too many production installations running with http or untrusted TLS settings to believe that only developers will use this option if it's made available.
I didn't think Devstack could easily deploy with SSL enabled, but it looks like you can: So http support might not be as important as I thought. It could be relegated to a documentation issue for deploying Devstack in this mode when deploying with Kubernetes. We'd still need a way to specify the root CA though for Keystone.
So, I played around with this a little. For my current non devstack based system, I've deployed kubernetes as a cluster running on my laptop deployed as a set of pods via /etc/kubernetes/manifests. Only kubelet is native and all the rest of the services are containers direct from google. Its working well, but since I have 3 api server containers, and get the containers direct from google, I'd have to jump through a bunch of hoops to add the keystone ssl ca cert to each of the containers. I still think an option to specify the ssl cert for keystone would be useful rather then having to merge it into the system's chain of trust.
That's how I'd want to handle this as well


Question: SeLinuxLabel:  e2epod.GetLinuxLabel(), NodeSelection: node, PVCsReadOnly:  readOnly, <del> ImageID:       e2epod.GetTestImageID(imageutils.DebianIptables), </del> <ins> ImageID:       e2epod.GetTestImageID(imageutils.JessieDnsutils), </ins> } pod, err := e2epod.CreateSecPodWithNodeSelection(cs, &podConfig, f.Timeouts.PodStart) defer func() {

From here we see that the method takes 512 bytes sector size as a default option for verifying block read. This makes the test fail for the block devices that uses 4k sector size because the read is using . However, with modern kernels the area being operated on, must be aligned to and its size must be a multiple of the disk's block size. So using dd iflag=direct with size 512B on a 4k sector size device will fail. This is introduced in this PR: There should be proper handling of different block sector size for the test. Either a customizable parameter or something. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /cc /sig storage
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
cc
Since we are using Debian image for this test. I am wondering does it make sense to use instead of for the dd read? I guess my question is if we use , while it read after the cache is dropped or before?
Or I am wondering can we just change the size to 4096. A read/write to the multiply of the sector size should be okay I guess?
I am not sure that option is available now, notes from September last year () indicate I tried that as well. I think you still need to write blocks of 512 or 4096 bytes, not sure if (or the kernel) is smart enough to split larger requests into smaller blocks. has a pointer to detect the blocksize dynamically, which would be a cleaner way and more future proof.
I am not sure when you mention the "option is not available" you mean for busybox or debian. I think for this specific test we are using Debian image which has this option.

Yes, this is what we use in the test and we found the test fail because in our case shows 4096 instead of 512
The option () used to be only applicable for (in Debian and CentOS) with , not with . I do not know if the Debian image was updated, and if it contains a new that supports the option.
+1 for using 4096 bytes. Or even more, 1MiB? Kernel/dd is smart and it will handle sequence of well.
I think that it's OK to just use large block size if there's no issue by doing so. However, I've made a PoC implementation of auto detect logic of sector size to compare alternative ideas. One issue is that current debian-iptables image that is used for this test doesn't contain blockdev command. In the PoC code, it is installed on execution time, however it should be included in the image, by either (1) adding it to debian-iptables image or (2) creating a new image that include it. If the issue can be resolved easily, this alternative approach will also be good.
I found that image contains both command and command and can be used for this test. I think that this additional detection logic is simple enough, so I made a PR above. Could you review it?


Question: return resourceSeries } <del> // Code for getting container name of docker, copied from pkg/kubelet/cm/container_manager_linux.go // since they are not exposed const ( kubeletProcessName    = "kubelet" dockerProcessName     = "docker" dockerPidFile         = "/var/run/docker.pid" containerdProcessName = "docker-containerd" containerdPidFile     = "/run/docker/libcontainerd/docker-containerd.pid" ) </del> <ins> const kubeletProcessName = "kubelet" </ins> func getPidsForProcess(name, pidFile string) ([]int, error) { if len(pidFile) > 0 {

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Now, benchmark test make docker as the only runtime. What you expected to happen: benchmark test should be generic to all CRI container runtimes Related to How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area test /area node-e2e
/sig node


Question: p.SuggestedCmdUsage = fmt.Sprintf("Use '%s describe pod/%s' to see all of the containers in this pod.", p.FullCmdName, p.PodName) } <del> namespace, _, err := f.DefaultNamespace() if err != nil { return err } p.Namespace = namespace </del> config, err := f.ClientConfig() if err != nil { return err

I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.


Question: func NewHyperKubeCommand(stopCh <-chan struct{}) (*cobra.Command, []func() *cobra.Command) { // these have to be functions since the command is polymorphic. Cobra wants you to be top level // command to get executed <del> apiserver := func() *cobra.Command { ret := kubeapiserver.NewAPIServerCommand(stopCh) // add back some unfortunate aliases that should be removed ret.Aliases = []string{"apiserver"} return ret } controller := func() *cobra.Command { ret := kubecontrollermanager.NewControllerManagerCommand() // add back some unfortunate aliases that should be removed ret.Aliases = []string{"controller-manager"} return ret } proxy := func() *cobra.Command { ret := kubeproxy.NewProxyCommand() // add back some unfortunate aliases that should be removed ret.Aliases = []string{"proxy"} return ret } scheduler := func() *cobra.Command { ret := kubescheduler.NewSchedulerCommand() // add back some unfortunate aliases that should be removed ret.Aliases = []string{"scheduler"} return ret } </del> <ins> apiserver := func() *cobra.Command { return kubeapiserver.NewAPIServerCommand(stopCh) } controller := func() *cobra.Command { return kubecontrollermanager.NewControllerManagerCommand() } proxy := func() *cobra.Command { return kubeproxy.NewProxyCommand() } scheduler := func() *cobra.Command { return kubescheduler.NewSchedulerCommand() } </ins> kubectlCmd := func() *cobra.Command { return kubectl.NewDefaultKubectlCommand() } kubelet := func() *cobra.Command { return kubelet.NewKubeletCommand(stopCh) } cloudController := func() *cobra.Command { return cloudcontrollermanager.NewCloudControllerManagerCommand() }

Hyperkube supports a number of short aliases for commands, such as , , , , etc, rather than the longer , , , etc. There are comments indicating this is "unfortunate" and we still currently create these aliases in the hyperkube docker image: It'd be nice to simplify this, assuming we can find all uses of the short aliases and remove them. /kind cleanup Not sure which sig should own this, so tagging a few. /sig architecture cluster-lifecycle cli cc
interestingly, the command doesn't create the short aliases, though we also don't really use anywhere either.
I think we can just go ahead and start the deprecation cycle for this. WDYT? cc
cc as well
+1 to nuke it
/assign :wink: ok?
SGTM
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would like to work on it!
It seems like this issue was already solved in ?
I don't think the hyperkube code was changed in that PR, only the image?
Yes, thanks for your comment, can i try to fix it ?
I made a PR here: . Review/feedback/suggestions appreciated! :)
/assign /unassign
GitHub didn't allow me to assign the following users: Rand01ph.

Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /unassign 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 architecture cli /sig release Does anyone even still use hyperkube? Wouldn't they use kubeadm or k3s instead?
AFAIK, SAP (the company) still use hyperkube.
aks-engine deployer ( ) still uses hyperkube
Since this ticket is completed now. Can this todo be removed?
we are removing the whole thing :)


Question: package credentialprovider import ( <ins> "encoding/base64" </ins> "encoding/json" "io/ioutil" "os"

<!-- 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: docker now provides a new favorite way to store the credentials with the variable credsStore in the file it it is set to desktop, which will be using the executable docker-credential-desktop whose source code is docker-credential-desktop doesn't pad the auth field. So, if we use the command k8s credential provider won't be able to decode the field because of the error Failed to pull image "myrepo/myimage:tag": illegal base64 data at input byte What you expected to happen: Image pulled normally How to reproduce it (as minimally and precisely as possible): open docker config file, and have credsStore set to desktop. Run docker login and then use the to create a k8s dockerconfigjson secret, the error will directly show Anything else we need to know?: I wrote a patch that I will submit Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-19T12:38:36Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64" Cloud provider or hardware configuration: minikube version: v1.3.1 commit: OS (e.g: ): Mac Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig Apps
/remove-sig apps /sig auth /sig node cc to triage


Question: # If using a network plugin, extend the docker configuration to always remove # the network checkpoint to avoid corrupt checkpoints. # (https://github.com/docker/docker/issues/18283). <del> echo "Extend the default docker.service configuration" </del> <ins> echo "Extend the docker.service configuration to remove the network checkpiont" </ins> mkdir -p /etc/systemd/system/docker.service.d cat <<EOF >/etc/systemd/system/docker.service.d/01network.conf [Service] ExecStartPre=/bin/sh -x -c "rm -rf /var/lib/docker/network" EOF <ins> fi </ins> <del> systemctl daemon-reload </del> <ins> # Ensure TasksMax is sufficient for docker. # (https://github.com/kubernetes/kubernetes/issues/51977) echo "Extend the docker.service configuration to set a higher pids limit" mkdir -p /etc/systemd/system/docker.service.d cat <<EOF >/etc/systemd/system/docker.service.d/02tasksmax.conf [Service] TasksMax=infinity EOF </ins> <del> # If using a network plugin, we need to explicitly restart docker daemon, because # kubelet will not do it. </del> <ins> systemctl daemon-reload </ins> echo "Docker command line is updated. Restart docker to pick it up" systemctl restart docker <del> fi </del> } # This function assembles the kubelet systemd service file and starts it

Forked from Since m60, COS set 4000 pids limit for docker.service. However, currently all containerd-shims are also inside the cgroup, and they are per-container. Each containerd-shim has more than 10 threads based on the node size: It's not hard to hit the limit, say 100 3-container pods may hit the limit. We may want to: 1) Either patch kubernetes to change the limit to higher value; 2) Or patch COS directly, since this may be a regression for other COS user, too. /cc
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
cc/ I guess this is the cause for some docker failures you observed.


Question: func (proxier *metaProxier) OnEndpointsUpdate(oldEndpoints, endpoints *v1.Endpoints) { ipFamily, err := endpointsIPFamily(endpoints) if err != nil { <del> klog.Warningf("failed to update endpoints %s/%s with error %v", endpoints.ObjectMeta.Namespace, endpoints.ObjectMeta.Name, err) </del> <ins> klog.V(4).Infof("failed to update endpoints %s/%s with error %v", endpoints.ObjectMeta.Namespace, endpoints.ObjectMeta.Name, err) </ins> return }

<!-- 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: Setup a kubernetes cluster with dual stack enabled, set kube-proxy to "ipvs" proxy mode, many warnings are flooding in kube-proxy pod log, W0303 22:11:22. 1 ] failed to update endpoints kube-system/kube-scheduler with error failed to identify ipfamily for endpoints (no subsets) W0303 22:11:22. 1 ] failed to update endpoints kube-system/kube-controller-manager with error failed to identify ipfamily for endpoints (no subsets) W0303 22:11:24. 1 ] failed to update endpoints kube-system/kube-scheduler with error failed to identify ipfamily for endpoints (no subsets) W0303 22:11:24. 1 ] failed to update endpoints kube-system/kube-controller-manager with error failed to identify ipfamily for endpoints (no subsets) W0303 22:11:26. 1 ] failed to update endpoints kube-system/kube-scheduler with error failed to identify ipfamily for endpoints (no subsets) What you expected to happen: No such error logs How to reproduce it (as minimally and precisely as possible): Here is my setup step, I'm using a single master node setup, kubeadm init --pod-network-cidr=192.168.0.0/16,fc00::/112 --service-cidr=10.96.0.0/16,fd00::/112 --feature-gates=IPv6DualStack=true Change controller-manager cidr configuration --node-cidr-mask-size-ipv6=120 install calico 3.6.4 with dual stack enabled kube-proxy proxy mode set to "ipvs" featureGates: IPv6DualStack: true healthzBindAddress: "" hostnameOverride: "" iptables: masqueradeAll: false masqueradeBit: null minSyncPeriod: 0s syncPeriod: 0s ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler: "" strictARP: false syncPeriod: 0s kind: KubeProxyConfiguration metricsBindAddress: "" mode: "ipvs" Anything else we need to know?

: Linux Redhat 7.7 Environment: Kubernetes version (use ):v1.17.3 Cloud provider or hardware configuration: OS (e.g: ): Redhat 7.7 Kernel (e.g. ): 3.10.0-1062.4.1.el7.x8664 Install tools: kubeadm Network plugin and version (if this is a network-related bug): calico 3.6.4 Others:
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/assign
/remove-triage unresolved those warnings are harmless because those objects doesn't have endpoints addresses, thus no IP family, as you can see below: however, I think that if there are no endpoint addresses we should skip instead of logging, what do you think ?
It seems these printouts can be caused by headless services, please see;
Can endpoints support dual stack? From my understanding, it cannot support dual stack in v1.17. Why kube-proxy will check another ipFamily which is not configured? Here is the endpoints info under default ns from my cluster,
Another observation about dual stack supporting is I don't see ipv6 interface address in node status. Here is my interface configuration, and here is pod configuration, I see kubelet has already set ipv6 network in podCIDRs
The is reported by if you specify . Currently kubelet does not report both ipv4 and ipv6 addresses, that is not implemented yet. But public clouds do not let report the node but defines them themselves. At least set both addresses. So it depends on your environment.
endpoints on services with ClusterIP services are single family, with the same IPFamily than the ClusterIP. However, you can create endpoints manually, not associated to a service, or to a headless service (ClusterIP=None) with a mix of families. You opened the issue asking why do you have these errors logs If you check the endpoints of the services mentioned in the logs there are no addresses, hence the kube-proxy logs a WARNING because is not able to identify the IP family. Technically the warning is correct, but I think that if there are no addresses we shouldn't log the warning.

In order to not convert this issue in a placeholder for dual stack let's try to stick to the topic, for more general things we have a #k8s-dual-stack channel in slack.
Ok, I understand what you mentioned. From the implementation, this log behavior is correct. The other problem is kube-proxy is constantly logging the same error.
I think (please somebody correct me if I'm wrong) this is because the endpoints are checked periodically, per the control-loop / reconcile paradigm that kubernetes uses, so it tries to add those endpoints periodically
nodeIPs are only dual stack if the cloud-controller-manager updates it, on bare metal or without cloud-controller-manager you only see one address. I tried cloud-controller-manager in my openstack cluster and can get ipv4/ipv6 interface.
Thanks, I will create another issue for document.


Question: "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", "--proxy-server-host=__APISERVER_IP__", "--proxy-server-port=8132", <ins> "--sync-interval=5s", "--sync-interval-cap=30s", "--probe-interval=5s", </ins> "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" ] env:

After the gce-master-scale-performance started failing with errors like: https://k8s- In a sample run I see a lot of errors like: in konnectivity-server logs: Looks like we have to increase QPS limit for konnectivity-server, do we have a flag (kube-env?) for that? /cc /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cloud-provider
/priority critical-urgent
We may need to re-open this, if there are still uncovered problems (or if we need to re-tune) after watching next test runs.
Wow, thanks a lot for such a rapid fix. Much appreciated!


Question: } else { rl.statusStack = "" } <del> rl.w.WriteHeader(status) } // Hijack implements http.Hijacker. func (rl *respLogger) Hijack() (net.Conn, *bufio.ReadWriter, error) { return rl.w.(http.Hijacker).Hijack() </del> }

From kube-, Kube-apiserver returns 200 as Success code upon some requests, otherwise return 0 as Success. I1102 20:11:33. 5 ] GET /api/v1/nodes/kubernetes-minion-3io1: (2.683448ms) 200 [[kubelet/v1.1.1 (linux/amd64) kubernetes/] 10.240.0.5:] I1102 20:11:33. 5 ] PUT /api/v1/nodes/kubernetes-minion-3io1/status: (5.474235ms) 200 [[kubelet/v1.1.1 (linux/amd64) kubernetes/] 10.240.0.5:] I1102 20:11:34. 5 ] GET /api/v1/nodes: (2.139174ms) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:37. 5 ] GET /api/v1/nodes/kubernetes-minion-jmxr: (1.452673ms) 200 [[kubelet/v1.1.1 (linux/amd64) kubernetes/] 10.240.0.3:] I1102 20:11:37. 5 ] PUT /api/v1/nodes/kubernetes-minion-jmxr/status: (4.833358ms) 200 [[kubelet/v1.1.1 (linux/amd64) kubernetes/] 10.240.0.3:] I1102 20:11:38. 5 ] GET /healthz: (104.272µs) 0 [[Go 1.1 package http] 127.0.0.1:] I1102 20:11:39. 5 ] GET /api/v1/watch/persistentvolumes?resourceVersion=1687: (9.998412938s) 0 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:39.

5 ] GET /api/v1/watch/persistentvolumeclaims?resourceVersion=1687: (10.000876825s) 0 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:39. 5 ] GET /api/v1/watch/persistentvolumes?resourceVersion=1687: (9.998155747s) 0 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:39. 5 ] GET /api/v1/watch/namespaces?resourceVersion=1667: (59.977954152s) 0 [[heapster/v1.0.3 (linux/amd64) kubernetes/$Format] 10.240.0.5:] I1102 20:11:39. 5 ] GET /api/v1/nodes: (1.471292ms) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:40. 5 ] GET /api/v1/persistentvolumes: (884.225µs) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:40. 5 ] GET /api/v1/persistentvolumeclaims: (942.355µs) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:40. 5 ] GET /api/v1/persistentvolumes: (1.065416ms) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:] I1102 20:11:40. 5 ] GET /api/v1/namespaces: (1.441822ms) 200 [[heapster/v1.0.3 (linux/amd64) kubernetes/$Format] 10.240.0.5:] I1102 20:11:40.

5 ] GET /api/v1/nodes: (1.958739ms) 200 [[kube-controller-manager/v1.1.1 (linux/amd64) kubernetes/] 127.0.0.1:]
If it were only the watches I would understand, but it's pretty weird for /healthz.
Looking into this, this is likely a false alarm due to an error in pkg/httplog. It assumes that everything calls does. In this case, the status is defaulted to 200. From the So when you just write, the httplog package doesn't see the status and assumes it's 0. I'm going to work on reproducing, confirming, then fixing this.
I confirmed with curl that this is just a logging error at least for healthz. Status code actually returns was 200. This is also pretty obvious since someone writing a 0 status code would result in a stacktrace in the log.
Watches are a different issue than healthz. I think watches are hijacked, and that kinda disables all status recording ability by this package. Do we care to fix that?
websockets hijack-- I thought watches did ordinary HTTP chunked encoding? , krousey wrote:
Probably, but the way it's currently implemented, hijacking completely bypasses this middle-ware logging layer we have.
Maybe we detect hijacking and log that instead of false data? e.g. would become
works for me! , krousey wrote:
Ok out for review in


Question: // including settings for: // // - Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize <del> // node subnet or services subnet. </del> <ins> // pod subnet or services subnet. </ins> // // - Etcd configurations; use it e.g. to customize the local etcd or to configure the API server // for using an external etcd cluster.

<!-- 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 --I was reading the doc about NodeRegistration, with an interest in specifying some . I noticed that the doc (e.g., ) does not tell me exactly how to identify each arg: exactly as on the command line (including leading dash(es)), as on the command line but without leading dash(es), or camelCase. I expected the doc to enable me to write some with confidence. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle
FWIW the answer is flag names as on the command name but without any leading dashes. This also applies to controllerManager.extraArgs, scheduler.extraArgs, etc. which hopefully should all cover this similarly (if not now, after fixing ...)

<!-- 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 --I was reading about how to use kubeadm and noticed a typo in the API documentation. speaks of the "node subnet" where I think "pod subnet" is intended. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle
/area kubeadm


Question: }, VirtualServer{}, true, <del> fmt.Sprintf("IPVS Service Flags should be >= %d, got 0x1", FlagHashed), </del> <ins> fmt.Sprintf("IPVS Service Flags should include %x, got 0x1", FlagHashed), </ins> }, { libipvs.Service{

The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)


Question: assert.Contains(t, x.output, "test-error Run") assert.EqualError(t, x.err, "Server returning error") } <ins> func TestCobraCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --help") assert.NoError(t, x.err) assert.Contains(t, x.output, "A server named test-cobra-command which uses a cobra command") assert.Contains(t, x.output, cobraMessageDesc) } func TestCobraCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command") assert.Contains(t, x.output, fmt.Sprintf("msg: %s", defaultCobraMessage)) } func TestCobraCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --msg foobar") assert.Contains(t, x.output, "msg: foobar") } func TestCobraSubCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --help") assert.NoError(t, x.err) assert.Contains(t, x.output, cobraSubMessageDesc) } func TestCobraSubCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand") assert.Contains(t, x.output, fmt.Sprintf("submsg: %s", defaultCobraSubMessage)) } func TestCobraSubCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --submsg foobar") assert.Contains(t, x.output, "submsg: foobar") } </ins>

When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .


Question: return runningPods } <del> var _ = SIGDescribe("Restart [Serial] [Slow] [Disruptive] [NodeFeature:ContainerRuntimeRestart]", func() { </del> <ins> var _ = SIGDescribe("Restart [Serial] [Slow] [Disruptive]", func() { </ins> const ( // Saturate the node. It's not necessary that all these pods enter // Running/Ready, because we don't know the number of cores in the

<!-- 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 --Restart: Always pods went into OutOfCpu error state after kubelet restart. Pods should remain running as node had sufficient capacity for them. Completed, RestartNever pod should not revert from Completed to OutOfCpu. Launch kubelet with: Run the following script against the local cluster: <details</detailsObserve pod status: Restart the kubelet: Observe pods: xref /sig node Kubernetes version (use ): v1.23.0-alpha.3.183+ - Cloud provider or hardware configuration: Local machine OS (e.g: ) & Kernel (e.g. ):Install tools: local-up- Network plugin and version (if this is a network-related bug): N/A Others:
/triage accepted /priority critical-urgent Reproducible on 1.22
From the reproducer: yields However, in the kubelet logs, it sees 7100m cpu allocated?
Looks like the topology admit handler thinks that the completed pods are using CPU which is why when it gets to the 8th it fails it with OutOfCpu. Must be a bug in there somewhere.
/assign
Unclear if could be related but linking for posterity
Confirmed this only affects 1.22, repro on 1.21 has expected behaviour: /sig scheduling I'll start a bisect.
is
Added some logging With this we see I think that the terminated pods are getting filtered, but for whatever reason they are still getting their resource requests to NodeInfo?
points out that my logging language was a bit backwards and that the completed pods should not have been returned, because they already successfully completed and exited. This code is suspect: The logs show that the completed pods are never filtered, so they are failing one of these checks. I am going to try to write a test case that hits this issue so we can test fixes against it.

The completed pods definitely show up as complete, but for some reason they do not get filtered (note I have changed my patch above for the log lines to make sense now): So I guess isPodTerminationRequested=true on already exited pods, but I would only expect that to be true if the pod was actively in the process of termination and not already exited. cc Log patch: <details</details
I tried changing to but apparently it thinks that's true :( Edit: doesn't work either.
The bug is that the only component in the kubelet that is allowed to authoritatively state a container is terminated (pod worker) takes non-zero time to do so during startup (because we have to call kill container to guarantee it's stopped). This races with the pod config loop and admission, which sends all the containers at once. In order for the race to be eliminated, some equivalent of a sync has to be completed during startup on terminal but potentially non-terminated pod workers BEFORE other adds are processed. That could be running HandlePodCleanups once all sources are synced but before HandlePod* methods are called, but HandlePodAdditions() cannot be invoked until after the pod worker has had a chance to verify all terminal pods are actually terminal. EDIT: Another potential approach is for the pod worker to hold starting pods until SyncKnownPods observes all terminal pods are accounted for at least once, then allowing starts.
Also, we appear to be missing a kubelet restart test that verifies admission with completed pods (which I thought was on our list of "missing e2e tests that would have caught these regressions" already). Such a test would have to: pods that consume resources for admission until they are running some of them with failed and` successful states the kubelet some of the running pods the kubelet none of the terminal pods are restarted, all running pods are restarted, and that only non-terminal pods are accounted to admission


Question: // If we have more than the maximum, sort the update entries by time, oldest first. sort.Slice(updaters, func(i, j int) bool { <del> iTime, jTime, nTime := managed.Times()[updaters[i]], managed.Times()[updaters[j]], &metav1.Time{Time: time.Time{}} if iTime == nil { iTime = nTime </del> <ins> iTime, jTime, iSeconds, jSeconds := managed.Times()[updaters[i]], managed.Times()[updaters[j]], int64(0), int64(0) if iTime != nil { iSeconds = iTime.Unix() </ins> } <del> if jTime == nil { jTime = nTime </del> <ins> if jTime != nil { jSeconds = jTime.Unix() </ins> } <del> if !iTime.Equal(jTime) { return iTime.Before(jTime) </del> <ins> if iSeconds != jSeconds { return iSeconds < jSeconds </ins> } return updaters[i] < updaters[j] })

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


Question: "//pkg/scheduler/testing:go_default_library", "//pkg/scheduler/util:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library",

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.

If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.


Question: w.Write([]byte(output)) } <ins> redirectHandler := func(s int, bad bool) func(w http.ResponseWriter, r *http.Request) { return func(w http.ResponseWriter, r *http.Request) { if r.URL.Path == "/" { http.Redirect(w, r, "/new", s) } else if bad && r.URL.Path == "/new" { w.WriteHeader(http.StatusInternalServerError) } } } </ins> prober := New() testCases := []struct { handler    func(w http.ResponseWriter, r *http.Request)

It seems the http liveness probe will not follow a 302 redirect and instead reports a failure. I found this in some testing on 1.0.6 and have not yet verified the same behavior on latest. Do you agree that it should check the redirected path on a 302? If so, where would be the best place to check the response code and handle this?
Why would you set your health-check URL to a redirect? , Dan Wilson wrote:
In this case it was a versioned health check where /v1/health or /v2/health is the correct check and /health directs to the correct one.
hmm, I could buy following redirects, I guess. It's a little weird if it redirects off-host, but who am I to say it is wrong? , Dan Wilson wrote:
Following redirects for a health check seems weird to me as well... I definitely wouldn't expect it to by default.
Seems like it would be cleaner to make respond the same as instead of making all health consumers follow redirects.
I agree that it's cleaner to call /health and make that route the same as /<latest/health but due to the framework used for this project it's not handled that way. Following the HTTP standards is important as well, right? curl handles this with an additional option (-L), could we do the same by adding a parameter?
I think it should follow local redirects without complaining (can well differentiate local vs non?). The real question is non-local redirects - should it a) work, b) not work, c) work iff a flag-field in the probe , Dan Wilson wrote:
old thread here... I agree with non-local redirects not being allowed, just doesn't seem to make sense. If we get a 301 perhaps we could get the value of the redirect ( it looks like there is a Location header with the new full path ) and then do something like the following: the root URL of the redirect location. it's a DNS name attempt to resolve it to an IP. If that fails, just bail. the IP to make sure it's in the cluster. If it's not in our CIDR block bail. the redirect. thoughts?

/sig node /sig network
Adding to 1.8 milestone
Is it not possible and easier to simply empower the user by adding an option for "unexceptional" status codes? They could declare 200-only (default) or all-but-errors.
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.9 milestone for more than 3 days: priority: Must specify exactly one of , or . <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
This contradicts docs , opened


Question: EmptyDir *EmptyDir `json:"emptyDir"` // GCEPersistentDisk represents a GCE Disk resource that is attached to a // kubelet's host machine and then exposed to the pod. <del> GCEPersistentDisk *GCEPersistentDisk `json:"persistentDisk"` </del> <ins> GCEPersistentDisk *GCEPersistentDisk `json:"gcePersistentDisk"` </ins> // GitRepo represents a git repository at a particular revision. GitRepo *GitRepo `json:"gitRepo"` }

As long as we have it in the API, it should maybe be renamed to gcePersistentDisk ?
SGTM


Question: } if len(b.resources) != 0 { <del> return &Result{err: fmt.Errorf("resource(s) were provided, but no name, label selector, or --all flag specified")} </del> <ins> for _, r := range b.resources { _, err := b.mappingFor(r) if err != nil { return &Result{err: err} } else { return &Result{err: fmt.Errorf("resource(s) were provided, but no name, label selector, or --all flag specified")} } } </ins> } return &Result{err: missingResourceError} }

Hello! I got this error: or:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Do I need to use ?
use instead


Question: DEBUG=${DEBUG:-"false"} <ins> # Add SSH_OPTS: Add this to config ssh port SSH_OPTS="-oPort=22 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oLogLevel=ERROR" </ins>

Hi, Right now in the installation script for Ubuntu there are hardcoded SSH_OPTS. In my case I am using a custom SSH port, and, unless I am mistaken, I have no way to customize it, either globally or on a per-host basis. Would it be possible to do that? I can try to submit a patch if necessary. Thanks.
Yes, please. Just send a PR to add in and make it configurable.


Question: // provide object, or returns an error. func (d *YAMLOrJSONDecoder) Decode(into interface{}) error { if d.decoder == nil { <del> buffer, origData, isJSON := GuessJSONStream(d.r, d.bufferSize) </del> <ins> buffer, _, isJSON := GuessJSONStream(d.r, d.bufferSize) </ins> if isJSON { d.decoder = json.NewDecoder(buffer) <del> d.rawData = origData </del> } else { d.decoder = NewYAMLToJSONDecoder(buffer) } } err := d.decoder.Decode(into) <del> if jsonDecoder, ok := d.decoder.(*json.Decoder); ok { if syntax, ok := err.(*json.SyntaxError); ok { data, readErr := ioutil.ReadAll(jsonDecoder.Buffered()) if readErr != nil { klog.V(4).Infof("reading stream failed: %v", readErr) } js := string(data) // if contents from io.Reader are not complete, // use the original raw data to prevent panic if int64(len(js)) <= syntax.Offset { js = string(d.rawData) } start := strings.LastIndex(js[:syntax.Offset], "n") + 1 line := strings.Count(js[:start], "n") return JSONSyntaxError{ Line: line, Err:  fmt.Errorf(syntax.Error()), } </del> <ins> if syntax, ok := err.(*json.SyntaxError); ok { return JSONSyntaxError{ Offset: syntax.Offset, Err:    syntax, </ins> } } return err

This bug was privately disclosed and told to open here. What happened: NewYAMLOrJSONDecoder from has an index out of bounds issue which can cause callers to panic. Download attached reproducer file Run golang test: When run with v0.19.3: Additionally, this can be seen in kubectl directly (below is kubectl 1.20.0): Environment: Kubernetes version (use ): Verified with 1.19, 1.20
/sig api-machinery
This piece attempts to find line+column position of a json syntax error. To do that it assumes that full input is available which is not true: is : is only the first data chunk: The subject happens e.g. when syntax error offset is past buffer size and Test to reproduce the panic: I am not sure it is easily possible to find line+column of json syntax error as full input may not be available. Maybe it should only attempt to find line+column if offset is within the first chunk (i.e. below buffer size).
Line number calculation in and updated in
do you want to submit a patch to with a defensive check to avoid the panic ( compare and )
I have raised a discussion on having line number in the . The consensus there is that it should be possible to count lines with a full input at hand and it does not worth to have it in the core library due to performance impact and maintenance costs. The problem of here is that it attempts to find out line number without having full input at hand. I think the defensive patch is not the right approach because line calculation is incorrect anyway even when there is no panic: begins at a value with a syntax error, i.e. in a stream of two values and syntax error in the second value it would contain only the second value and thus new lines in the first value in the stream would not be counted. I think the following options are there: to stream taken from . This is straightforward but changes interface. I can not find any code that uses field, it is only used in the error message that would change: line number only if offset is within the length of the first data chunk (). I am not sure what would be the unknown line number then, perhaps. line number properly during stream decoding, see This has some performance penalty as line number is calculated in any case even if there is no syntax error, i.e.

in the majority of the cases.
cc /triage accepted
This is probably acceptable.
I have opened a PR
Thank you for support.


Question: } for _, test := range testCases { <del> ss, err := newTestScaleSet(ctrl, test.scaleSet, test.zone, test.faultDomain, test.vmList) </del> <ins> cloud := GetTestCloud(ctrl) if test.location != "" { cloud.Location = test.location } setTestVirtualMachineCloud(cloud, test.scaleSet, test.zone, test.faultDomain, test.vmList, "Running") scaleset, err := newScaleSet(cloud) </ins> assert.NoError(t, err, test.description) <ins> ss := scaleset.(*scaleSet) </ins> real, err := ss.GetZoneByNodeName(test.nodeName) if test.expectError {

<!-- 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: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .


Question: return true } <del> // AreLabelsInWhiteList verifies if the provided label list // is in the provided whitelist and returns true, otherwise false. func AreLabelsInWhiteList(labels, whitelist Set) bool { if len(whitelist) == 0 { return true } for k, v := range labels { value, ok := whitelist[k] if !ok { return false } if value != v { return false } } return true } </del> // ConvertSelectorToLabelsMap converts selector string to labels map // and validates keys and values func ConvertSelectorToLabelsMap(selector string) (Set, error) {

What happened: The function return when whitelist is empty. The function is implemented as follows: What you expected to happen: When the whitelist is empty, any key of labels can not in it. Should the function return when whitelist is empty?
/sig api-machinery
/assign /cc (we think you might have opinions on fixing this)
I only see one consumer. Rather than change the semantic, I would suggest moving it to the point of use and renaming it.
Yes, this function is wrong, I agree with David. P.S. we don't advertise interface stability for this library so this is OK. But even if we did, I think callers of this function are probably not expecting this behavior and should be examined.) P.P.S. The way it should work is via set difference, the labels should be a subset of the list. P.P.P.S. These are sets and not lists, and the names should be changed to reflect that. P.P.P.P.S. If you're making a change here anyway, please lose the word "whitelist".
Okay, I will submit a pr.


Question: - [Metrics Changes](#metrics-changes) - [Added metrics](#added-metrics) - [Removed metrics](#removed-metrics) <del> - [Depreciated/changed metrics](#depreciatedchanged-metrics) </del> <ins> - [Deprecated/changed metrics](#deprecatedchanged-metrics) </ins> - [Notable Features](#notable-features) - [Beta](#beta) - [Alpha](#alpha)

What happened: There's a typo typo in and What you expected to happen: “depreciated” should be “deprecated”. How to reproduce it (as minimally and precisely as possible): View the release notes Anything else we need to know?: /lifecycle active I have a PR to fix this /sig docs Environment: Kubernetes version (use ): v1.16 Cloud provider or hardware configuration: not applicable OS (e.g: ): not applicable Kernel (e.g. ): not applicable Install tools: not applicable


Question: } for _, pod := range pods.Items { <del> for _, c := range pod.Spec.Containers { </del> <ins> for i, c := range pod.Spec.Containers { </ins> name := pod.ObjectMeta.Name + "/" + c.Name <del> if logging[name] { </del> <ins> if logging[name] || // sanity check, array should have entry for each container len(pod.Status.ContainerStatuses) <= i || // Don't attempt to get logs for a container unless it is running or has terminated. // Trying to get a log would just end up with an error that we would have to suppress. (pod.Status.ContainerStatuses[i].State.Running == nil && pod.Status.ContainerStatuses[i].State.Terminated == nil) { </ins> continue } readCloser, err := LogsForPod(ctx, cs, ns, pod.ObjectMeta.Name,

When running some GCE PD CSI Driver E2E tests this warning gets printed out repeatedly. Looks like it's in a tight retry loop. 1) What needs to be fixed so that this error doesn't happen? 2) If it does error out, can it retry a couple times then give up. Right now it just continuously prints these warning statements drowning out any other log signals. /cc not sure who has the most context on this <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig storage
I wrote that code. The error message comes from this API here: And gets printed here: The code gets triggered by pod events. At least to me it wasn't clear when log retrieval is supposed to succeed and when it is expected to fail, so the operation simply gets retried until it succeeds. If this "the server does not allow this method on the requested resource" error is normal and can be ignored, then it can be to the regex in and then it'll get suppressed.
/assign
These particular logs might be from the daemonset pod that is trying to run on the master node
Michelle Au <: It looks like test logs are incomplete (). If true, then this permission issue permanently prevents capturing log output. Does anyone have an idea how to get logs in this setup?
I'm not sure about that, the logs show: as the driver running on the node. Edit: This is not ture, this could still be the master node, the daemonset names all its pods like this
I think it would be much better if we could figure out the source of the error and remedy it instead of turning off logs for server errors altogether
The log spam is making it really difficult to run the tests locally:
Saad Ali <: As you can reproduce it, do you have an explanation for why this permission error occurs? All I can do is suppress the error, but I think we all agree that this shouldn't be done without understanding the issue first.
I haven't confirmed but I think it's from the daemonset pod that is trying to unsuccessfully run on the master node. I think we could try to skip pods that are not actually running
FWIW it only happens when the test is failing.
Saad Ali <: So perhaps it really has to do something with trying to get logs for pods that couldn't start? Does help?


Question: // update initiatorname params["iface.initiatorname"] = b.InitiatorName // create new iface <del> out, err = b.exec.Run("iscsiadm", "-m", "iface", "-I", newIface, "-o", "new") </del> <ins> out, err = b.exec.Run("iscsiadm", "-m", "iface", "-I", b.Iface, "-o", "new") </ins> if err != nil { exit, ok := err.(utilexec.ExitError) if ok && exit.ExitStatus() == iscsiadmErrorSessExists { <del> klog.Infof("iscsi: there is a session already logged in with iface %s", newIface) </del> <ins> klog.Infof("iscsi: there is a session already logged in with iface %s", b.Iface) </ins> } else { lastErr = fmt.Errorf("iscsi: failed to create new iface: %s (%v)", string(out), err) return lastErr

What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign


Question: "github.com/blang/semver" dockertypes "github.com/docker/engine-api/types" <ins> dockernat "github.com/docker/go-connections/nat" </ins> "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require"

This is in 1.6.0-beta.4: Some context: The line number suggests it is here: I think this is because dockershim now uses a protobuf object and Protocol is now an int. And is allowed in go (apparently) - is "A". And the comedic error is because Protocol implements If this is the error, there's something fishy going on because all our UDP tests should fail?
Aha ... I think it is only UDP hostports that would be "broken" by the issue. I wouldn't be surprised if we don't rely on any, and that we might not have any test coverage. I don't think this is a regression - I think this code has been there since the start of dockershim, but maybe CRI is now the default? I don't know how widely UDP hostports are used. Given how close we are to the planned release date, cc and
There is something wrong in dockershim's protocol parsing. Will file an PR to fix this. /assgin
/assign
Opened to fix this.
thanks for filing the issue. Thanks for quickly addressing the bug. We need node e2e tests to capture the kind of regression at the first place.


Question: return v.configuration.Load().([]webhook.WebhookAccessor) } <del> // HasSynced returns true if the shared informers have synced. </del> <ins> // HasSynced returns true when the manager is synced with existing webhookconfig // objects at startup-- which means the informer is synced and either has no items // or updateConfiguration() has completed. </ins> func (v *validatingWebhookConfigurationManager) HasSynced() bool { <del> return v.hasSynced() </del> <ins> if !v.hasSynced() { return false } if v.initialConfigurationSynced.Load().(bool) { // the informer has synced and configuration has been updated return true } if configurations, err := v.lister.List(labels.Everything()); err == nil && len(configurations) == 0 { // the empty list we initially stored is valid to use. // Setting initialConfigurationSynced to true, so subsequent checks // would be able to take the fast path on the atomic boolean in a // cluster without any admission webhooks configured. v.initialConfigurationSynced.Store(true) // the informer has synced and we don't have any items return true } return false </ins> } func (v *validatingWebhookConfigurationManager) updateConfiguration() {

<!-- 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: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/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
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
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: } if glog.V(10) { for _, hostPriority := range results[index] { <del> glog.Infof("%v -> %v: %v, Score: (%d)", pod.Name, hostPriority.Host, config.Name, hostPriority.Score) </del> <ins> glog.Infof("%v -> %v: %v, Score: (%d)", util.GetPodFullName(pod), hostPriority.Host, config.Name, hostPriority.Score) </ins> } } }(i, priorityConfig)

<!-- Please only use this template for submitting enhancement requests --What would you like to be : In pkg/scheduler/core/generic_scheduler# , add some debug info: each scheduler extender's score and its name for each pod, e.g. And we need add a function(e.g. ) in interface to get extender's name or similar identity. For , it might be enough to return its url . Why is this needed: If there are two or more scheduler extenders configured for scheduler(and we have now), it will be very useful to debug why kubelet nodes get so high/low score. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
Reiterating the mentions to trigger a notification: <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Why don't you send a PR instead?
Thanks. PR is sent. PTAL.


Question: "kuberuntime_sandbox_test.go", "labels_test.go", "legacy_test.go", <del> "security_context_test.go", </del> <ins> "security_context_others_test.go", "security_context_windows_test.go", </ins> ], embed = [":go_default_library"], deps = [

Hello, What happened: When we apply PodSecurityPolicy with rule: WIndows containers are still blocked instead we put: the pod is still blocked with logs: What you expected to happen: the Container should start How to reproduce it (as minimally and precisely as possible): Create Psp disableling Root Users: Create a pod Windows with runAsUserName: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.3 Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux 7 (Core) / windows server 2019 version 1809 Kernel (e.g. ): 3.10.0-514.10.2.el7.x86_64 Others: /sig windows
/sig windows
/assign I will test it and then post the test results
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: // +optional optional string volumeMode = 6; <del> // This field requires the VolumeSnapshotDataSource alpha feature gate to be // enabled and currently VolumeSnapshot is the only supported data source. // If the provisioner can support VolumeSnapshot data source, it will create // a new volume and data will be restored to the volume at the same time. // If the provisioner does not support VolumeSnapshot data source, volume will </del> <ins> // This field can be used to specify either: // * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) // * An existing PVC (PersistentVolumeClaim) // In order to use VolumeSnapshot object types, the appropriate feature gate // must be enabled (VolumeSnapshotDataSource) // If the provisioner can support the specified data source, it will create // a new volume based on the contents of the specified PVC or Snapshot. // If the provisioner does not support the specified data source, the volume will </ins> // not be created and the failure will be reported as an event. // In the future, we plan to support more data source types and the behavior // of the provisioner may change.

/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /sig api 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