jiebi/CodeConvo huggingface dataset:
Change:
return cmdutil.AddSourceToErr(fmt.Sprintf("retrieving original configuration from:n%vnfor:", info), info.Source, err) } <ins> // Create the versioned struct from the original from the server for // strategic patch. // TODO: Move all structs in apply to use raw data. Can be done once // builder has a RawResult method which delivers raw data instead of // internal objects. versionedObject, _, err := decoder.Decode(current, nil, nil) if err != nil { return cmdutil.AddSourceToErr(fmt.Sprintf("converting encoded server-side object back to versioned struct:n%vnfor:", info), info.Source, err) } </ins> // Compute a three way strategic merge patch to send to server. <del> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, info.VersionedObject, true) </del> <ins> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, versionedObject, true) </ins> if err != nil { format := "creating patch with:noriginal:n%snmodified:n%sncurrent:n%snfrom:n%vnfor:" return cmdutil.AddSourceToErr(fmt.Sprintf(format, original, modified, current, info), info.Source, err)

Discussion:
kubectl create, delete, etc. can already take a List object. kubectl apply can take the list object when it does creation, but it gives an (ugly) error when it's configuring the objects. Then... expected: Actual:
what's you ?
0-alpha.5
Sounds like a bug. Are you interested in taking a look
sure I will take a look during this weekend.
I think the root cause is , the actually is , in the origin , is not , but after the , this object is nil. Would you like to double check this?
I'll take a look.
if you have make sure about this, please let me know. Thanks :)
Is there any ways we could get this into 1.2? It's actually making our config generation quite painful to have to make a separate file for every object. It looks like got pretty far? would you like to make a PR that we can review?
I don't see how. It could have made 1.2 if a PR had been sent within a few days of the issue being filed.
I unassigned all issues assigned to you. Please only assign issues that are actively being worked on, so that others can know which issues are available to be picked up.
My apologies. If I'm not mistaken, this issue was filed after the code freeze for 1.2. I didn't realize that it was time critical or that it could make the release at that time. However, I should have asked. Sorry for the inconvenience. Thank you. I still plan to address those issues for the next release, as discussed, but will assign each one to myself as I work on it.
I created which fixes this. I'm really hoping we can get this into 1.2 since it's a pretty small, isolated fix but a pretty big bug that is complicating our config generation system. Let me know what else I can do to help.
Thanks for the PR. We're short on reviewer bandwidth at the moment. I assigned it to Clayton for review or delegation.
Change:
type cacheWatcher struct { sync.Mutex copier  runtime.ObjectCopier <del> input   chan *watchCacheEvent </del> <ins> input   chan watchCacheEvent </ins> result  chan watch.Event done    chan struct{} filter  watchFilterFunc

Discussion:
Our scalability tests started failing on Thu last week: https://k8s- [250 run passed, 251 failed and since then everything failed] I started looking into it and it seems that something happened to how we are handling watches (i.e. I'm seeing a huge number of watches failing with "err too old" errors (which I didn't see before).
As an example in run 258 of kubemark-scale, I'm seeing this log in the test (after 5 minutes of running test); This is extremely strange and unexpected. I looked into apiserver logs, and there is expected number of POST and PUT operations on pods (and no DELETE and PATCH operations until then). Until then, there were alltogethere ~60.000 operations on pods. However, in 5000-node cluster, the size of watchcache of pods is supposed to be 250.000, which means that at that moment we should have all the history from the beginning in watch cache. And still we are observing those errors. Something must have changed around that recently...
As an example, logs from apiserver from a given node: This means something is really wrong: the first watch started at 45, then after it finished, we tried starting watch from rv= and it failed with "rv too old" the list, returned rv= from which we started the next watch. If the watch cache size for pods would be 250.000 (50*cluster size), there there is no way that with current rv=, the rv= would be outside history window...
I had a hypothesis that it might be the problem of breaking watch to etcd. But in that case there should be a warning "Terminating all watchers" log in apiserver, and there is no such log. It also seems that the size of cache is being set correctly...
So I tried running large kubemark locally and it seems that the problem is that the size of cache is too small. I few more logs, and here is what I'm seeing: So it seems that we are correctly initializing cachesizes, but then watch cache capacity is 100 (which explains why we are seeing all those "rv too old" errors. I will try to debug why the capacity is so small.
OK - I found it. contains the fix.
Change:
return fmt.Errorf("Failed to resize replication controller %s to zero: %v", name, err) } <del> if err := wait.Poll(time.Second, time.Minute*20, client.ControllerHasDesiredReplicas(c, rc)); err != nil { return fmt.Errorf("Error waiting for replication controller %s replicas to reach 0: %v", name, err) </del> <ins> // Wait up to 20 minutes until all replicas are killed. endTime := time.Now().Add(time.Minute * 20) for { if time.Now().After(endTime) { return fmt.Errorf("Timeout while waiting for replication controller %s replicas to 0", name) } remainingTime := endTime.Sub(time.Now()) err := wait.Poll(time.Second, remainingTime, client.ControllerHasDesiredReplicas(c, rc)) if err != nil { glog.Errorf("Error while waiting for replication controller %s replicas to read 0: %v", name, err) } else { break } </ins> } // Delete the replication controller.

Discussion:
In Jenkins scalability suite, Density test is failing on cleanup: Expected error: <*errors.errorString | 0xc20d27c460: { s: "Error waiting for replication controller my-hostname-density3000--e362-11e4-90b1- replicas to reach 0: Get http://127.0.0.1:4001/v2/keys/registry/controllers/default/my-hostname-density3000--e362-11e4-90b1-?quorum=false&recursive=false&sorted=false: dial tcp 127.0.0.1:4001: cannot assign requested address", } Error waiting for replication controller my-hostname-density3000--e362-11e4-90b1- replicas to reach 0: Get http://127.0.0.1:4001/v2/keys/registry/controllers/default/my-hostname-density3000--e362-11e4-90b1-?quorum=false&recursive=false&sorted=false: dial tcp 127.0.0.1:4001: cannot assign requested address not to have occurred We need some retrying while waiting for rc to be deleted (similar to what I've done for waiting for all replicas in )
This just happened again on Jenkins.
Change:
}}, }, } volume := &ec2.Volume{ AvailabilityZone: aws.String("us-east-1a"), VolumeId:         aws.String("vol-volumeId0"), <ins> State:            aws.String("available"), </ins> } awsServices.ec2.(*MockedFakeEC2).On("CreateVolume", request).Return(volume, nil) <ins> describeVolumesRequest := &ec2.DescribeVolumesInput{ VolumeIds: []*string{aws.String("vol-volumeId0")}, } awsServices.ec2.(*MockedFakeEC2).On("DescribeVolumes", describeVolumesRequest).Return([]*ec2.Volume{volume}, nil) </ins> volumeID, err := c.CreateDisk(volumeOptions) assert.Nil(t, err, "Error creating disk: %v", err) assert.Equal(t, volumeID, KubernetesVolumeID("aws://us-east-1a/vol-volumeId0"))

Discussion:
What happened: Kubernetes tries to attach EBS volumes while their status is still : I believe this started to happen after , when volumes and their tags started to be created in the same request. Before that, tags would be set through another call (i.e., ), which retries if the volume isn't . What you expected to happen: Kubernetes should try to attach the volume only when it's available. In order to do that, should make sure the volume is when it returns. How to reproduce it (as minimally and precisely as possible): Just create a dynamically provisioned EBS volume. /kind bug /sig storage /sig aws
CC
What is the downside of this? IIRC - even when we tagged separately, we used to have few cases where by the time attachment was attempted, volume was not available. May be tagging while creating the volume makes it worse but someone has to wait for volume to become available - either attach call or create volume call itself.
In worse case this causes first attach to fail - but controller will retry anyway.
I think it re-introduces
No - looking at events attached to the pod, it looks like volume eventually got attached. I think is unrelated.
It is related. If you create volume with invalid keys, AWS returns you a volume and in this case Kubernetes will create a PV for it. But then the volume silently disappears. The only way how to detect that is to wait for the volume to either get Available or disappear.
we are still waiting for volume to become available if volume has kms key -
+1 on this issue. I have seen this quite often on my v1.12 cluster too. So this is an issue even before
we are still waiting for volume to become available if volume has kms key - Oh, sorry for the noise.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
EBS CSI driver is already regardless of whether kms key is used or not. Any objections to do the same for in-tree?
I like it.
Change:
"cs":     "componentstatuses", "ev":     "events", "limits": "limitRanges", <del> "mi":     "minions", </del> <ins> "no":     "nodes", </ins> "po":     "pods", "pv":     "persistentVolumes", "pvc":    "persistentVolumeClaims",

Discussion:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

I know that you can get nodes / a node, but the help doesn't say you can or provide examples: To resolve this issue: the help for this command to include nodes (and any other resources we're missing). we generate the help text in a way that ensures this (and probably the many others that are drifting) don't get out of date? Or at least give us a heuristic as to whether this might be true, even if we have to fix it manually?
Can this be closed?
I'll close this one with ; we want to get rid of the minions (mi) resource name, since it doesn't work for v1beta3.
Change:
} } <del> if a.jwtAuthenticator.ClaimMappings.Username.Prefix != nil && *a.jwtAuthenticator.ClaimMappings.Username.Prefix != "" { username = *a.jwtAuthenticator.ClaimMappings.Username.Prefix + username </del> <ins> userNamePrefix := a.jwtAuthenticator.ClaimMappings.Username.Prefix if userNamePrefix != nil && *userNamePrefix != "" { username = *userNamePrefix + username </ins> } info := &user.DefaultInfo{Name: username} <del> if a.jwtAuthenticator.ClaimMappings.Groups.Claim != "" { if _, ok := c[a.jwtAuthenticator.ClaimMappings.Groups.Claim]; ok { </del> <ins> groupsClaim := a.jwtAuthenticator.ClaimMappings.Groups.Claim if groupsClaim != "" { if _, ok := c[groupsClaim]; ok { </ins> // Some admins want to use string claims like "role" as the group value. // Allow the group claim to be a single string instead of an array. // // See: https://github.com/kubernetes/kubernetes/issues/33290 var groups stringOrArray <del> if err := c.unmarshalClaim(a.jwtAuthenticator.ClaimMappings.Groups.Claim, &groups); err != nil { return nil, false, fmt.Errorf("oidc: parse groups claim %q: %v", a.jwtAuthenticator.ClaimMappings.Groups.Claim, err) </del> <ins> if err := c.unmarshalClaim(groupsClaim, &groups); err != nil { return nil, false, fmt.Errorf("oidc: parse groups claim %q: %v", groupsClaim, err) </ins> } info.Groups = []string(groups) } } <del> if a.jwtAuthenticator.ClaimMappings.Groups.Prefix != nil && *a.jwtAuthenticator.ClaimMappings.Groups.Prefix != "" { </del> <ins> groupsPrefix := a.jwtAuthenticator.ClaimMappings.Groups.Prefix if groupsPrefix != nil && *groupsPrefix != "" { </ins> for i, group := range info.Groups { <del> info.Groups[i] = *a.jwtAuthenticator.ClaimMappings.Groups.Prefix + group </del> <ins> info.Groups[i] = *groupsPrefix + group </ins> } }

Discussion:
Follow up PR: would be good to use some local vars to make these statements shorter. Originally posted by in
/sig auth /triage accepted /kind cleanup /assign
Change:
// TODO(liggitt): drop this once golang json parser limits stack depth (https://github.com/golang/go/issues/31789) if len(p.patchBytes) > 1024*1024 { v := []interface{}{} <del> if err := json.Unmarshal(p.patchBytes, v); err != nil { </del> <ins> if err := json.Unmarshal(p.patchBytes, &v); err != nil { </ins> return nil, errors.NewBadRequest(fmt.Sprintf("error decoding patch: %v", err)) } }

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 --What happened: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code 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 api-machinery
/assign
Change:
return err } <del> // TODO: This shouldn't be needed, see corresponding TODO in StatefulSetHasDesiredReplicas. // StatefulSet should track generation number. pods := reaper.podClient.Pods(namespace) selector, _ := metav1.LabelSelectorAsSelector(ss.Spec.Selector) options := metav1.ListOptions{LabelSelector: selector.String()} podList, err := pods.List(options) if err != nil { return err } errList := []error{} for i := range podList.Items { pod := &podList.Items[i] controllerRef := controller.GetControllerOf(pod) // Ignore Pod if it's an orphan or owned by someone else. if controllerRef == nil || controllerRef.UID != ss.UID { continue } if err := pods.Delete(pod.Name, gracePeriod); err != nil { if !errors.IsNotFound(err) { errList = append(errList, err) } } } if len(errList) > 0 { return utilerrors.NewAggregate(errList) } </del> // TODO: Cleanup volumes? We don't want to accidentally delete volumes from // stop, so just leave this up to the statefulset. falseVar := false

Discussion:
StatefulSet now as of 1.6. That means the TODO on can be fixed in 1.7. We could not fix it in 1.6 because that code is used by kubectl, which must work against servers that are one minor version ahead of or behind the client.
/cc
I am volunteered to take this job if no one start working on this.
I don't think anyone's working on it, so you are welcome to take it. Feel free to tag me as a reviewer. Thanks!
Change:
TEMP_DIR:=$(shell mktemp -d) ifeq ($(ARCH),amd64) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base:buster-v1.2.0 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base:buster-v1.3.0 </ins> endif ifeq ($(ARCH),arm) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm:buster-v1.2.0 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm:buster-v1.3.0 </ins> endif ifeq ($(ARCH),arm64) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm64:buster-v1.2.0 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm64:buster-v1.3.0 </ins> endif ifeq ($(ARCH),ppc64le) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-ppc64le:buster-v1.2.0 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-ppc64le:buster-v1.3.0 </ins> endif ifeq ($(ARCH),s390x) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-s390x:buster-v1.2.0 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-s390x:buster-v1.3.0 </ins> endif RUNNERIMAGE?=gcr.io/distroless/static:latest

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
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
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
finalAttached:        true, trigerWatchEventTime: 5 * time.Millisecond, timeout:              50 * time.Millisecond, <del> sleepTime:            5 * time.Millisecond, </del> shouldFail:           false, }, {

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
"github.com/onsi/ginkgo" ) <del> var _ = SIGDescribe("DNS", func() { </del> <ins> var _ = SIGDescribe("[Feature:Windows] DNS", func() { </ins> ginkgo.BeforeEach(func() { e2eskipper.SkipUnlessNodeOSDistroIs("windows")

Discussion:
What happened: Some of our windows tests (in this case ) dont add enough scheduling metadata to behave predictably in environments where, for example, is required to interpret a pods proper location. A "bug" in EKS CNI actually causes EKS, for example, to not properly label such pods with IP addresses (because it uses an adm controller to add metadata before a pod is created, and that md is sent to eks's cni). In any case adding this metadata is a standard in Sig-windows, per conv with yesterday, so we'll want to add these in. As an example of the test failure which results when you dont have this selector.... Looking at the pod Spec: 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: ): 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 windows
Change:
groupVersion := gvr.GroupVersion() result := c.client.clientBase.Patch(pt). AbsPath(c.client.apiPathFor(groupVersion)). <del> Namespace(c.namespace). </del> <ins> NamespaceIfScoped(c.namespace, c.namespace != ""). </ins> Resource(gvr.Resource). Name(name). SubResource("scale").

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The scale client () currently works fine with namespaced resources. However, it doesn't work for non-namespaced resources e.g. cluster-scoped CRDs. The current implementation should be extended in order to support non-namespaced resources. The current interface: /area custom-resources /sig autoscaling
I think scale subresource support for CRDs falls more into sig-apimachinery domain. After DirectXMan12 moved on from sig-autoscaling I don't think there is anyone in our sig-autoscaling with knowledge of scale subresource internals. /sig api-machinery
/assign
The bug report sounds legit. Does the generic scale client need to be changed (I think so), or does solve your issue?
No, the dashboard PR doesn't solve this. I discovered this issue while working on that PR so when gets merged, it will only work for namespaced CRDs. I think the generic scale client needs to be updated, maybe by adding another getter to the ScalesGetter interface: /kind bug
PR:
Change:
minimumGCAge            = flag.Duration("minimum_container_ttl_duration", 0, "Minimum age for a finished container before it is garbage collected.  Examples: '300ms', '10s' or '2h45m'") maxContainerCount       = flag.Int("maximum_dead_containers_per_container", 5, "Maximum number of old instances of a container to retain per container.  Each container takes up some disk space.  Default: 5.") authPath                = flag.String("auth_path", "", "Path to .kubernetes_auth file, specifying how to authenticate to API server.") <ins> cAdvisorPort            = flag.Uint("cadvisor_port", 4194, "The port of the localhost cAdvisor endpoint") </ins> apiServerList           util.StringList )

Discussion:
Currently, kubelet uses a for communicating with cAdvisor. , were having an issue because we didn't realize making port available was required for kubernetes.
I prefer not do this since we plan to make 4194 publically reserved port for cAdvisor. Also cAdvisor is the default deamon running on every node of a kubernetes cluster. The issue you encountered sounds like a bad document issue we had for cAdvisor. We should fix the document instead of allow the port being configurable.
can you expound on 'bad document' issue?