jiebi/CodeConvo huggingface dataset:
Change:
#  TIMEOUT: For REMOTE=true only. How long (in golang duration format) to wait #    for ginkgo tests to complete. Defaults to 45m. #  PARALLELISM: The number of ginkgo nodes to run.  Defaults to 8. <del> #  RUNTIME: Container runtime to use (eg. docker, remote). #    Defaults to "docker". </del> #  CONTAINER_RUNTIME_ENDPOINT: remote container endpoint to connect to. <del> #    Used when RUNTIME is set to "remote". </del> <ins> #    Defaults to "/run/containerd/containerd.sock". </ins> #  IMAGE_SERVICE_ENDPOINT: remote image endpoint to connect to, to prepull images. #    Used when RUNTIME is set to "remote". #  IMAGE_CONFIG_FILE: path to a file containing image configuration.

Discussion:
$ make test-e2e-node fails with an error because of the docker deprecation. I think we have to fix the default options for helper scripts. $ make test-e2e-node succeeds in common cases by default. $ make test-e2e-node No response_ <details</details<details</details<details</details<details</details<details</details<details</details/assign
/sig node
/cc
/assign
/triage accepted /assign /priority important-soon
Change:
IMAGE=staging-k8s.gcr.io/kube-addon-manager ARCH?=amd64 TEMP_DIR:=$(shell mktemp -d) <del> VERSION=v8.7 </del> <ins> VERSION=v8.8 </ins> KUBECTL_VERSION?=v1.10.7 <del> ifeq ($(ARCH),amd64) BASEIMAGE?=bashell/alpine-bash endif ifeq ($(ARCH),arm) BASEIMAGE?=arm32v7/debian endif ifeq ($(ARCH),arm64) BASEIMAGE?=arm64v8/debian endif ifeq ($(ARCH),ppc64le) BASEIMAGE?=ppc64le/debian endif ifeq ($(ARCH),s390x) BASEIMAGE?=s390x/debian endif </del> <ins> BASEIMAGE=k8s.gcr.io/debian-base-$(ARCH):0.3.2 </ins> .PHONY: build push

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature Alpine fixed a RCE vulnerability in apk in 3.8.1 () Update the base image used for addon-manager () to pick it up. Note: I'd send a PR if it depended directly on alpine image, not bashell/alpine.
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
/assing
Ping
Change:
name: new-kms-provider-for-configmaps cachesize: 1000 endpoint: unix:///@new-kms-provider.sock <ins> - resources: - '*.*' providers: - kms: name: kms-provider-to-encrypt-all cachesize: 1000 endpoint: unix:///@new-encrypt-all-kms-provider.sock - identity: {} </ins> ` <ins> // start new KMS Plugin _ = mock.NewBase64Plugin(t, "@new-encrypt-all-kms-provider.sock") </ins> // update encryption config and wait for hot reload if err := os.WriteFile(filepath.Join(test.configDir, encryptionConfigFileName), []byte(encryptionConfigWithoutOldProvider), 0644); err != nil { t.Fatalf("failed to update encryption config, err: %v", err) } <ins> wantPrefixForEncryptAll := "k8s:enc:kms:v1:kms-provider-to-encrypt-all:" </ins> // wait for config to be observed <del> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, test) </del> <ins> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, wantPrefixForEncryptAll, test) </ins> // confirm that reading secrets still works _, err = test.restClient.CoreV1().Secrets(testNamespace).Get(

Discussion:
transformation expandless | 14m1s Failed; === RUN TestEncryptionConfigHotReload TestEncryptionConfigHotReload When I see this flake, 10-09 is the first one.(But the job history in the testgrid only started from 10-03) some PR that may be related: /sig auth /cc
/cc
/triage accepted
/cc failed two times in recent 3 runs:
/reopen as of this is still .
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
}, }, { <ins> name: "Pod copy: explicit attach", args: "mypod --image=busybox --copy-to=my-debugger --attach -- sleep 1d", wantOpts: &DebugOptions{ Args:           []string{"sleep", "1d"}, Attach:         true, CopyTo:         "my-debugger", Image:          "busybox", Namespace:      "default", ShareProcesses: true, TargetNames:    []string{"mypod"}, }, }, { </ins> name: "Pod copy: replace single image of existing container", args: "mypod --image=busybox --container=my-container --copy-to=my-debugger", wantOpts: &DebugOptions{

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: Using without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that
Change:
if !ok { cacheSize = f.Options.DefaultWatchCacheSize } <ins> // depending on cache size this might return an undecorated storage </ins> ret.Decorator = genericregistry.StorageWithCacher(cacheSize) }

Discussion:
Currently we signal undecorated storage by simply affecting the undecoratedStorage to the decorator. This is a blocker for kubernetes/enhancements as we need to enable watch cache for events (which currently hardcoded and not configurable) cc /assign /sig api-machinery
Change:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Build the fluentd-elasticsearch image and push # to google/fluentd-elasticsearch. sudo docker build -t kubernetes/fluentd-elasticsearch . sudo docker push kubernetes/fluentd-elasticsearch </ins>

Discussion:
After PR , I did a bit experiments on kube-dns graceful termination and got some unintended result as below: I guess it is because the other container was terminated before . DNS query from clients failed because is the actual connection point. After a bit discussion with and two solutions for this are: another program wrap up the dnsmasq and capture the SIGTERM signal. out a way to modify the sig mask of process without touching the original codes.
Something I have been meaning to try: Put in Dockerfile Build and push image We should deliver SIGCONT rather than SIGTERM. I did a quick test and it seems to work. Otherwise trapping SIGTERM in the shell and ignoring it is well documented... , Zihong Zheng wrote:
Thanks, I will take a look and test these.
Change:
kubectl replace "${kube_flags[@]}" --force -f /tmp/tmp-valid-pod.json # Post-condition: spec.container.name = "replaced-k8s-serve-hostname" kube::test::get_object_assert 'pod valid-pod' "{{(index .spec.containers 0).name}}" 'replaced-k8s-serve-hostname' <ins> ## check replace --grace-period requires --force output_message=$(! kubectl replace "${kube_flags[@]}" --grace-period=1 -f /tmp/tmp-valid-pod.json 2>&1) kube::test::if_has_string "${output_message}" '--grace-period must have --force specified' ## check replace --timeout requires --force output_message=$(! kubectl replace "${kube_flags[@]}" --timeout=1s -f /tmp/tmp-valid-pod.json 2>&1) kube::test::if_has_string "${output_message}" '--timeout must have --force specified' </ins> #cleaning rm /tmp/tmp-valid-pod.json

Discussion:
When replacing an existing pod, the command fails as it tries to create a pod with a name that is still used by terminating pod. How does the option works? deletes a pod (e.g. mypod) creates a new pod with the same name (mypod) What happens? As the command tries to recreate the pod, it fails as the is in state. Thus it can not be created. The problem is the does not wait for a pod to be deleted. Reproducer: run mypod --image=yapei/hello-openshift --generator=run-pod/v1 get pod mypod -o yaml replace -f --force The last command ends with:
option introduce by
With set to positive value, what should be the default behaviour of the command? When set to , should the command hang for and then create the pod? Or is there a way to create a callback (inside a scheduler?) that creates the pod once the current one is deleted?
You could watch for the resource to be deleted and create after you see the deletion happen
have you ever tried to set , I think this will do a non graceful deletion. should make sure the old resource is deleted before it creates a new resource, if not, that's a bug.
Though the help says the is to be used only with , it returns the error above.
Then I think there are two issues we need to track: 1. option should be ignored or just returns error if users are not using option. 2. should always make sure the old resource has been deleted before create the new resource.
Change:
eventsRule(), }, }, <ins> { // a role making the csrapprover controller approve a node client CSR ObjectMeta: metav1.ObjectMeta{Name: "system:certificates.k8s.io:certificatesigningrequests:nodeclient"}, Rules: []rbac.PolicyRule{ rbac.NewRule("create").Groups(certificatesGroup).Resources("certificatesigningrequests/nodeclient").RuleOrDie(), }, }, { // a role making the csrapprover controller approve a node client CSR requested by the node itself ObjectMeta: metav1.ObjectMeta{Name: "system:certificates.k8s.io:certificatesigningrequests:selfnodeclient"}, Rules: []rbac.PolicyRule{ rbac.NewRule("create").Groups(certificatesGroup).Resources("certificatesigningrequests/selfnodeclient").RuleOrDie(), }, }, } if utilfeature.DefaultFeatureGate.Enabled(features.RotateKubeletServerCertificate) { roles = append(roles, rbac.ClusterRole{ // a role making the csrapprover controller approve a node server CSR requested by the node itself ObjectMeta: metav1.ObjectMeta{Name: "system:certificates.k8s.io:certificatesigningrequests:selfnodeserver"}, Rules: []rbac.PolicyRule{ rbac.NewRule("create").Groups(certificatesGroup).Resources("certificatesigningrequests/selfnodeserver").RuleOrDie(), }, }) </ins> } addClusterRoleLabel(roles) return roles }

Discussion:
/kind feature From: Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like. I'm asking because it's already duplicated twice for two early adopters: I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles?
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism.
You could individually revoke this role from the group and stop renewals without disrupting regular operation
I can definitely see myself revoking a binding from to multiple specific bindings in case of a compromise. Anyway, this issue is more "should we create these by default or not". I've already mentioned my opinion.
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer.
Perfect, that's exactly my proposal. I'll go ahead and make this change...
/assign
are you working on this or should I send a PR?
Change:
framework.Logf("Sleeping 10 seconds and crossing our fingers that scheduler will run in that time.") time.Sleep(10 * time.Second) <del> verifyResult(c, labelPodName, 2, 0, ns) </del> <ins> verifyResult(c, labelPodName, 3, 1, ns) </ins> }) // test the pod affinity successful matching scenario with multiple Label Operators.

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Looking into this...
trying to track this flake down. It looks like the pod is launched despite AntiAffinity in . In my local setup I saw the same, but noticed that the new admission controller was not activate.

I have activate it and now get this:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Should be fixed by
Change:
docker_pull( name = "debian-hyperkube-base-amd64", <del> digest = "sha256:1a05a58432254268c31ef5c8d9c21f3d01a40611b14707de6ac2772c0793bd13", </del> <ins> digest = "sha256:fc1b461367730660ac5a40c1eb2d1b23221829acf8a892981c12361383b3742b", </ins> registry = "gcr.io", repository = "google-containers/debian-hyperkube-base-amd64", <del> tag = "0.7",  # ignored, but kept here for documentation </del> <ins> tag = "0.8",  # ignored, but kept here for documentation </ins> ) docker_pull(

Discussion:
the new hyperkube image has changed without notifying the bash environment now links to sh, there is only one thing worst than an error, and it is a SILENT ERROR this means that anyone that execute kubectl inside the hyperkube and leverage from a bash environment now get the weirdest exceptions , in my case troubles where caused by flexvolume scripted in bash which stopped working without reason and with weird errors logged ( but also there are some other cluster-images based on your hyperkube image, and if you link bash to sh it will spread headache around :) ) while for version 1.7.7 the result was different so , or remove bash, or repristinate bash, link bash-sh is a NO-NO
/assign /sig node
Change:
<ins> # This configuration file for Fluentd / td-agent is used # to watch changes to Docker log files that live in the # directory /var/lib/docker/containers/ which are then submitted to # Elasticsearch (running on the machine ES_HOST:9200) which # assumes the installation of the fluentd-elasticsearch plug-in. # See https://github.com/uken/fluent-plugin-elasticsearch for # more information about the plug-in. This file needs to be # patched to replace ES_HOST with the name of the actual # machine running Elasticsearch. # Maintainer: Satnam Singh (satnam@google.com) # # Exampe # ====== # A line in the Docker log file might like like this JSON: # # {"log":"2014/09/25 21:15:03 Got request with path wombatn", #  "stream":"stderr", #   "time":"2014-09-25T21:15:03.499185026Z"} # # The time_format specification below makes sure we properly # parse the time format produced by Docker. This will be # submitted to Elasticsearch and should appear like: # $ curl 'http://elasticsearch:9200/_search?pretty' # ... # { #      "_index" : "logstash-2014.09.25", #      "_type" : "fluentd", #      "_id" : "VBrbor2QTuGpsQyTCdfzqA", #      "_score" : 1.0, #      "_source":{"log":"2014/09/25 22:45:50 Got request with path wombatn", #                 "stream":"stderr","tag":"docker.container.all", #                 "@timestamp":"2014-09-25T22:45:50+00:00"} #    }, # ... <source> type tail format json time_key time path /var/lib/docker/containers/*/*-json.log time_format %Y-%m-%dT%H:%M:%S tag docker.container.all </source> <match docker.container.*> type elasticsearch log_level info include_tag_key true host ES_HOST port 9200 logstash_format true flush_interval 5s </match> </ins>

Discussion:
After PR , I did a bit experiments on kube-dns graceful termination and got some unintended result as below: I guess it is because the other container was terminated before . DNS query from clients failed because is the actual connection point. After a bit discussion with and two solutions for this are: another program wrap up the dnsmasq and capture the SIGTERM signal. out a way to modify the sig mask of process without touching the original codes.
Something I have been meaning to try: Put in Dockerfile Build and push image We should deliver SIGCONT rather than SIGTERM. I did a quick test and it seems to work. Otherwise trapping SIGTERM in the shell and ignoring it is well documented... , Zihong Zheng wrote:
Thanks, I will take a look and test these.
Change:
export KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" <ins> if [[ ! -f "${KUBE_ROOT}/vendor/BUILD" ]]; then echo "${KUBE_ROOT}/vendor/BUILD does not exist." echo echo "Run ./hack/update-bazel.sh" exit 1 fi </ins> # Remove generated files prior to running kazel. # TODO(spxtr): Remove this line once Bazel is the only way to build. rm -f "${KUBE_ROOT}/pkg/generated/openapi/zz_generated.openapi.go"

Discussion:
At this point I don't know if it is a valid file or not?
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
I reproduce it on my env. After removing , will not create and update ; Manually creating an empty file , will successfully rewrite and update ; /cc Seems file will not be created automatically if missing.
This is working as intended, or at least as designed. We only create new files if there are go sources in that directory, and doesn't have any go sources, so won't be auto-created. We have a solely for the and rules, but those are only managed in existing files. Without , we'd have a lot of lines in , which would be painful. I learned last week that the say to remove all of , which mucks with this process a little bit. I a step in the instructions there to recreate the file, but maybe should just be doing that? I'm not super excited about adding special cases there, but is kinda weird, so maybe it's unavoidable.
the more automatic the better
Specifically, this would cause many merge conflicts.
I'm a little confused, since this has been the way things have worked since merged in April, but 4+ people asking me about this in the last week have convinced me that this needs to be more automatic. Sent .
Change:
return canonicalVolumePath, nil } <ins> // getPathFromFileNotFound returns the path from a fileNotFound error func getPathFromFileNotFound(err error) (string, error) { if soap.IsSoapFault(err) { fault := soap.ToSoapFault(err) f, ok := fault.VimFault().(types.FileNotFound) if !ok { return "", fmt.Errorf("%v is not a FileNotFound error", err) } return f.File, nil } return "", fmt.Errorf("%v is not a soap fault", err) } </ins> func setdatastoreFolderIDMap( datastoreFolderIDMap map[string]map[string]string, datastore string,

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!--What happened: Provsioning a PVC using a storage class with vSphere as the cloud provider failed with error "runtime error: index out of range". What you expected to happen: The PVC should have been created. How to reproduce it (as minimally and precisely as possible): Create a PVC using a storage class with vSphere as the cloud provider and a VMware vCenter Server where the default language is not English. Anything else we need to know?: K8s in conjunction with vSphere PVC relies on English error messages from the VMware API in order to determine the canonical path for a newly created volume (VMDK file). The faulting code (v1.11.3, still the same on master) can be found here (starting at line 312): The line "canonicalVolumePath = match[1]" (340) in the above code is the problem because "File (.*?) was not found" (English) never matches for a different language (e.g. German: "Datei [DATASTORE] kubevols/kube- wurde nicht gefunden") and a “runtime error: index out of range” oocurs in the "kube-controller-manager". This causes the already created volume (VMDK file) not to be reported back to the K8s system which in turn will try to recreate it repeatedly in a loop (fails with "Cannot complete the operation because the file or folder [DATASTORE] /kubevols/kubernetes-dynamic-pvc-[UUID] already exists"). Find below the corresponding log excerpt (kube-controller-manager): Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): n/a Kernel (e.g. ): n/a Install tools: n/a Others: n/a <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign