jiebi/CodeConvo huggingface dataset:
Change:
package e2e_node import ( <del> "github.com/golang/glog" </del> "os/exec" <ins> "time" "github.com/golang/glog" </ins> ) const ( <del> busyBoxImage = iota </del> <ins> // Number of attempts to pull an image. maxImagePullRetries = 5 // Sleep duration between image pull retry attempts. imagePullRetryDelay = time.Second busyBoxImage        = iota </ins> hostExecImage netExecImage

Discussion:
Another image pull related failure: Looking at the docker logs, it looks like docker is getting a 404 pulling some of the images
The error message looks normal. Kubelet always inspects to check whether the image is present before pulling image. If the image is not present, docker will record 404 error in log. However, the wired thing is that, if we've already prepull images, the image should be present. :)
The logs are from May 2nd, when we didn't have the image prepulling. Closing the issue.
Change:
package registry import ( <ins> "context" </ins> "testing" "time"

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

I didn't see an option to use websockets with the go client the impl is at Is there another code path or go client that will use a websocket for Watches?
Technically I didn't say our go client, just a go client. I just had in mind using the raw websockets library. must be testing the websocket watches somehow?
I adapted to It will simply keep running - with no events after the timeout. If you switch to configmap, it will terminate.
that's a terrific reproducer, thanks!
Yeah, we should absolutely be able to stick that in a unit / integration test somewhere, thanks!
opened in configmap watch works correctly, service watch hits timeout without the server closing the connection
I suspect the issue is in newDecoratedWatcher. Services implement a decorator and configmaps don't.
yup, the request context wasn't propagated to the decorated watcher
Service decorator was in 1.20 in Fix with unit and integration test in Will pick to 1.21 and 1.20 once merged
/triage accepted
Change:
# Tests which kills or restarts components and/or nodes. DISRUPTIVE_TESTS=( <del> "AutoscalingsSuite.*scalescluster" </del> "DaemonRestart" "Etcdsfailure" "NodessResize"

Discussion:
Per our email discussion while getting 1.1 out the door. It looks like this never happened, though, which means we're not running autoscaling tests against GCE on the 1.1 branch, (we were running it on GKE with the 1.1-features job, but I'm removing that job in ). I'd once again like to (strongly) suggest that we mirror test suites running against release branch to jobs running against master, so that we avoid this problem of accidentally not running tests when we think we are. I'd much rather have a perhaps-unnecessary slow/HPA/whatever suite than continually try to figure out where slow/HPA/whatever tests are running, depending on if I'm looking at release jobs versus jobs running against master. cc
+1 We should be running the autoscaling tests in slow or continuous.
Change:
if c.Debug != nil { c.Debug.Logf("Calling custom conversion of '%v' to '%v'", st, dt) } <del> args := []reflect.Value{sv.Addr(), dv.Addr(), reflect.ValueOf(scope)} ret := fv.Call(args)[0].Interface() // This convolution is necessary because nil interfaces won't convert // to errors. if ret == nil { return nil } return ret.(error) </del> <ins> return c.callCustom(sv, dv, fv, scope) </ins> } if !scope.flags.IsSet(AllowDifferentFieldTypeNames) && c.NameFunc(dt) != c.NameFunc(st) {

Discussion:
In Go you cannot take the address of a because the map implementation hides that from you. Our conversion library assumes that any reflected map value can have Addr() taken, which causes a panic when you try to do the following for PodInfo conversion: The conversion code tries to call Addr() on the reflect.Value (the map's value, ContainerStatus value object) which fails because it cannot have an address. I worked around it by registering a conversion function on *PodInfo and then manually converting the map.
Oh you mean the reflection code can't addr that? ok sounds like a bug. Non-reflection code can certainly do it:
That playground is taking the address of a value before it's in the struct. You can't take the address of m ----- Original Message -----
Right, because go does magical c++ style references there. But I thought the map copying code handled that case specially already?
I think I see what you're talking about. I'll make a test.
I repro'd. Will fix.
It was actually the source value that caused the trouble. Thanks for the report!
Sorry, should have been clearer. ----- Original Message -----
Note that this map violates our API conventions. It should be a list of named subobjects.
Yeah this field has always been problematic. It's still a bug regardless-- could have triggered copying other maps.
Change:
expectedPrefix: "104", }, { <del> name:           "V6: Largest subnet currently supported", podSubnet:      "2001:db8::/66", expectedPrefix: "80", }, { </del> name:           "V6: For /64 pod net, use /80", podSubnet:      "2001:db8::/64", expectedPrefix: "80", }, <ins> { name:           "V6: For /48 pod net, use /64", podSubnet:      "2001:db8::/48", expectedPrefix: "64", }, { name:           "V6: For /32 pod net, use /48", podSubnet:      "2001:db8::/32", expectedPrefix: "48", }, </ins> } for _, test := range tests { actualPrefix := calcNodeCidrSize(test.podSubnet)

Discussion:
The comments in mention the IPv6 /66 restriction. This restriction was removed in PR Also, the unit tests show the /66 as the largest subnet. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: What you expected to happen: 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:
/assign rpothier
/sig cluster-lifecycle
/area ipv6
Change:
podRunCount := maxPodCount*(int(testDuration/jobDuration)-1) + 1 linesPerPod := linesPerPodPerSecond * int(jobDuration.Seconds()) <ins> // pods is a flat array of all pods to be run and to expect in Stackdriver. </ins> pods := []*loggingPod{} <ins> // podsByRun is a two-dimensional array of pods, first dimension is the run // index, the second dimension is the node index. Since we want to create // an equal load on all nodes, for the same run we have one pod per node. podsByRun := [][]*loggingPod{} </ins> for runIdx := 0; runIdx < podRunCount; runIdx++ { <ins> podsInRun := []*loggingPod{} </ins> for nodeIdx, node := range nodes { podName := fmt.Sprintf("job-logs-generator-%d-%d-%d-%d", maxPodCount, linesPerPod, runIdx, nodeIdx) <del> pods = append(pods, newLoggingPod(podName, node.Name, linesPerPod, jobDuration)) </del> <ins> pod := newLoggingPod(podName, node.Name, linesPerPod, jobDuration) pods = append(pods, pod) podsInRun = append(podsInRun, pod) </ins> } <ins> podsByRun = append(podsByRun, podsInRun) </ins> } By("Running short-living pods") go func() { <del> for _, pod := range pods { pod.Start(f) </del> <ins> for runIdx := 0; runIdx < podRunCount; runIdx++ { // Starting one pod on each node. for _, pod := range podsByRun[runIdx] { pod.Start(f) } </ins> time.Sleep(podRunDelay) <del> defer f.PodClient().Delete(pod.Name, &meta_v1.DeleteOptions{}) </del> } // Waiting until the last pod has completed time.Sleep(jobDuration - podRunDelay + lastPodIngestionSlack)

Discussion:
There's a problem b/c pods are created to run on all nodes, but run sequentially, effectively multiplying testing time
Change:
import ( "strings" "testing" <ins> "time" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors"

Discussion:
After the DST change: We should be ignoring creationTimestamp on update.
Could you please explain the cause of the failure in more detail? Do we not normalize the timezone in the representation used in the API?
When we serialize to JSON we are using a value that has a timezone embedded in it (time.Time). As a result the representation changed. We should normalize it as well during serialization, but in general creationTimestamp should not prevent an update since it can safely be ignored.
I think we should allow creationTimestamp to be empty and also convert time to UTC() before marshaling.
More specifically: We'd also want to change: to and to
Makes sense to me - clients should always control their timezone and with distributed masters you might see different values. ----- Original Message -----
I'll own the follow up on this. ----- Original Message -----
+1 for UTC serialization
Opened to marshal to utc when serializing
Change:
kube::util::wait_for_url "http://127.0.0.1:${CTLRMGR_PORT}/healthz" "controller-manager" } <del> function run_kubelet() { # Only run kubelet on platforms it supports if [[ "$(go env GOHOSTOS)" == "linux" ]]; then kube::log::status "Building kubelet" make -C "${KUBE_ROOT}" WHAT="cmd/kubelet" kube::log::status "Starting kubelet in masterless mode" "${KUBE_OUTPUT_HOSTBIN}/kubelet"  --really-crash-for-testing=true  --root-dir=/tmp/kubelet.$$  --cert-dir="${TMPDIR:-/tmp/}"  --docker-endpoint="fake://"  --hostname-override="127.0.0.1"  --address="127.0.0.1"  --port="$KUBELET_PORT"  --healthz-port="${KUBELET_HEALTHZ_PORT}" 1>&2 & KUBELET_PID=$! kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet(masterless)" kill ${KUBELET_PID} 1>&2 2>/dev/null kube::log::status "Starting kubelet in masterful mode" "${KUBE_OUTPUT_HOSTBIN}/kubelet"  --really-crash-for-testing=true  --root-dir=/tmp/kubelet.$$  --cert-dir="${TMPDIR:-/tmp/}"  --docker-endpoint="fake://"  --hostname-override="127.0.0.1"  --address="127.0.0.1"  --api-servers="${API_HOST}:${API_PORT}"  --port="$KUBELET_PORT"  --healthz-port="${KUBELET_HEALTHZ_PORT}" 1>&2 & KUBELET_PID=$! kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet" fi } # Creates a node object with name 127.0.0.1 if it doesnt exist already. # This is required for non-linux platforms where we do not run kubelet. </del> <ins> # Creates a node object with name 127.0.0.1. This is required because we do not # run kubelet. </ins> function create_node() { <del> if [[ "$(go env GOHOSTOS)" == "linux" ]]; then kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/api/v1/nodes/127.0.0.1" "apiserver(nodes)" else # create a fake node kubectl create -f - -s "http://127.0.0.1:${API_PORT}" << __EOF__ </del> <ins> kubectl create -f - -s "http://127.0.0.1:${API_PORT}" << __EOF__ </ins> { "kind": "Node", "apiVersion": "v1",

Discussion:
I am running locally which is failing with the following error: Is this expected? Is there a way to change that path? cc
starts kubelet as a normal user, which doesn't have the permission to create the socket in . I think we can create a new kubelet flag to pass this path. /cc
From test- at "# This command checks that the built commands can function together for simple scenarios. It does not require Docker." In this case, can we update this not require On another hand, why test-cmd requires a working Kubelet which does nothing today?
Yes kubectl tests should not really require kubelet. I think it should be fine to remove it if the tests pass without it. cc who own this I think.
See . It passed locally for me.
Change:
}, []string{"operation_type"}, ) <ins> EvictionStatsAge = prometheus.NewSummaryVec( prometheus.SummaryOpts{ Subsystem: KubeletSubsystem, Name:      EvictionStatsAgeKey, Help:      "Time between when stats are collected, and when pod is evicted based on those stats by eviction signal", }, []string{"eviction_signal"}, ) </ins> ) var registerMetrics sync.Once

Discussion:
We should keep track of how stale stats used for evictions are. This will help track improvements in eviction latency, and help uncover regressions. cc If someone could assign this to me, I would appreciate that.
closing via
Change:
containers: - name: influxdb image: gcr.io/google_containers/heapster_influxdb:v0.3 <ins> ports: - containerPort: 8083 hostPort: 8083 - containerPort: 8086 hostPort: 8086 </ins> - name: grafana image: gcr.io/google_containers/heapster_grafana:v0.6 env:

Discussion:
/sig gcp /sig cluster-life-cycle /kind flake /milestone v1.10 cc https://k8s- starting last night /assign can one of you verify?
/kind bug /priority important-soon
/priority critical-urgent /priority failing-test /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/assign according to , gonna move those jobs to us-central1-c instead
Change:
} // Remove all of our chains. <del> for _, ch := range iptablesChains { </del> <ins> for _, ch := range iptablesCleanupChains { </ins> if err := ipt.DeleteChain(ch.table, ch.chain); err != nil { if !utiliptables.IsNotFoundError(err) { klog.Errorf("Error removing iptables rules in ipvs proxier: %v", err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /sig network What happened: Kube-proxy () deployed as daemonset with ipvs mode produce during startup following error: With verbosity -v5 the logs looks like this: Looks like proxier is trying to perform cleanup part: but failed. Such error is generated only once during startup. What you expected to happen: Error should not exist :) Environment: Kubernetes version (use ): 1.11.1 Cloud provider or hardware configuration: none OS (e.g. from /etc/os-release): Ubuntu 16.04 LTS Kernel (e.g. ): Install tools: custom script based on docker Others:
I've build kube-proxy with additional information: and the logs looks like this:
same issue
Looks like also fixed this one.
I'm on 1.12.0 and the issue is still there I suppose is included in 1.12?
Updated my kube to 1.12.3 and I got same
I'm still seeing this on v1.12.4 as well
same here on v1.13.2, throws this error when kube-proxy initializes. Running on CoreOS in ipvs mode:
Hello, I also encountered this problem in Kubernetes 1.13.3. The operating system is CentOS 7.6. The kernel version is: Linux linux-node4 3.10.0-957.el7.x86_64
Why is this closed? It looks like an unresolved issue. I have the same errors with 1.12.1.
same as me
same as me,1.12.3
same problem OS: Ubuntu 18 kernel: 4.15.0-46-generic Kubernetes: 1.13.4
same problem OS: CentOS 7.6 kernel: 3.10.0-957.el7.x86_64 Kubernetes: 1.13.4
I met this issue on Centos 7.6 with NetworkManager installed, it seems related to the network.
Same problem OS: CentOS 7.4 Kubernetes: 1.12.5 NetworkManager not installed.

Some of the nodes does not have this issue while others do
I am getting in 1.14.0 as well in some worker nodes.
same problem,how to solve it
same problem 1.13.2 ,how fix it?
i update kube-proxy 1.14.2, the error message is disappear
same problem OS: Debian 8 Kubernetes: v1.15.0 iptables v1.4.21 kube-proxy mode ipvs I write some test code like kube-proxy --cleanup and found line 7 is , and run , the error is The problem is we should flush KUBE-LOAD-BALANCER and KUBE-NODE-PORT before delete KUBE-MARK-MASQ , I can try fix it.
Change:
"description": "Backend defines the referenced service endpoint to which the traffic will be forwarded to." }, "path": { <del> "description": "Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/'. When unspecified, all paths from incoming requests are matched.", </del> <ins> "description": "Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/' and must be present when using PathType with value "Exact" or "Prefix".", </ins> "type": "string" }, "pathType": {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --When I tried to use the default path I got . No error. According to the path is not needed. "When unspecified, all paths from incoming requests are matched." Create a ingress like so: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: brew Network plugin and version (if this is a network-related bug): N/A Others:
/sig network /area ingress It seems to be a problem of ingress and I suggest creating an issue in I find a similar one which is a little different there
We use - would this be a problem with the aws repo then?
/assign
So digging a bit here, the API docs needs to be improved. By the , is required if the PathPrefix is Exact or Prefix. To solve your issue specifically, you have two ways: Add that accepts ingress without paths Add and change PathPrefix to Prefix, so this becomes a catchAll I'll open a PR to fix the comment/docs. Thanks!
Thanks! In my case because I'm using ALB controller I had to use with prefix to get it working - see
/triage accepted PR will close this ;)
Change:
# Verify schema file="${KUBE_TEMP}/schema.json" <del> curl -kfs --oauth2-bearer admin-token "https://127.0.0.1:${SECURE_API_PORT}/openapi/v2" > "${file}" </del> <ins> curl -kfsS -H 'Authorization: Bearer admin-token' "https://127.0.0.1:${SECURE_API_PORT}/openapi/v2" > "${file}" </ins> grep -q "list of returned" "${file}" grep -q "List of services" "${file}" grep -q "Watch for changes to the described resources" "${file}"

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
// mount it globalPDPath := rbd.manager.MakeGlobalPDName(rbd) mountpoint, err := rbd.mounter.IsMountPoint(globalPDPath) <del> if err != nil { </del> <ins> // in the first time, the path shouldn't exist and IsMountPoint is expected to get NotExist if err != nil && !os.IsNotExist(err) { </ins> return fmt.Errorf("rbd: %s failed to check mountpoint", globalPDPath) } if mountpoint {

Discussion:
I find questionable, as the check always fails when directory doesn't exist, and it's being created .
nice reading. The basic idea is to ensure the directory is not already mounted before rbd starts to use this directory to mount the device. you'll find kubelet checks the volume mount periodically. If kubelet finds the volume is already mounted, it won't mount it again. This is why kubelet probes the existence of mount point.
But then who's going to bootstrap the directory if is never reached? I managed to get out of this loop only by issuing myself, after which the pod started up.
if is not reached, something wrong happened. Do you have a kubelet log I can peek?
btw, are you still using containerized kubelet?
Kubelet isn't containerized (is that even possible to use one with rbd mounts?)
looks i made a regression
opened to fix it, thank you for spotting this problem!