jiebi/CodeConvo huggingface dataset:
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: [] [sig-node] PreStop should call prestop when killing a pod [Conformance] Since when has it been failing: N/A Testgrid link: N/A Reason for failure: When spawning a Pod, it's container might start before all its networking plumbing has been completed. Thus, if the container tests / needs its network connectivity, it mgiht fail. The ` image tries to connect to the Kubernetes API, but if it cannot, the Pod will end up in an Error state. Retrying the Kubernetes API connection will avoid this issue. Anything else we need to know:
/sig node
/remove-sig node /sig testing

Discussion:
deps = [ "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/version:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", ],

v1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apimachinery/pkg/version" </ins> clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest" )

// Find all sibling pods in the service and post to their /write handler. func contactOthers(state *State) { <ins> var ( versionInfo *version.Info err         error ) </ins> sleepTime := 5 * time.Second // In large cluster getting all endpoints is pretty expensive. // Thus, we will limit ourselves to send on average at most 10 such

if err != nil { log.Fatalf("Unable to create client; error: %vn", err) } <del> // Double check that worked by getting the server version. if v, err := client.Discovery().ServerVersion(); err != nil { log.Fatalf("Unable to get server version: %vn", err) } else { log.Printf("Server version: %#vn", v) </del> <ins> // Try to get the server version until <timeout>; we use a timeout because // the pod might not have immediate network connectivity. for start := time.Now(); time.Since(start) < timeout; time.Sleep(sleepTime) { // Double check that worked by getting the server version. if versionInfo, err = client.Discovery().ServerVersion(); err != nil { log.Printf("Unable to get server version: %v; retrying.n", err) } else { log.Printf("Server version: %#vn", versionInfo) break } time.Sleep(1 * time.Second) } if err != nil { log.Fatalf("Unable to contact Kubernetes: %vn", err) </ins> } for start := time.Now(); time.Since(start) < timeout; time.Sleep(sleepTime) {
Change:
What happened: Looks like KEP organization changed and the component-base kep in the readme doesn't link anymore. What you expected to happen: Link to go to the right document. How to reproduce it (as minimally and precisely as possible): click link - Anything else we need to know?: n/a Environment: n/a
/sig cluster-lifecycle /sig api-machinery
/assign EDIT: oops looks like the PR is already up

Discussion:
## Purpose <del> Implement KEP 32: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/0032-create-a-k8s-io-component-repo.md </del> <ins> Implement KEP 32: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/0032-create-a-k8s-io-component-repo.md </ins> The proposal is essentially about refactoring the Kubernetes core package structure in a way that all core components may share common code around: - ComponentConfig implementation
Change:
<!-- 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: use an existing azure file share name should be possible in azure file plugin 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: /sig azure /assign

Discussion:
} share := fileClient.GetShareReference(name) share.Properties.Quota = sizeGiB <del> if err = share.Create(nil); err != nil { </del> <ins> newlyCreated, err := share.CreateIfNotExists(nil) if err != nil { </ins> return fmt.Errorf("failed to create file share, err: %v", err) } <ins> if !newlyCreated { klog.V(2).Infof("file share(%s) under account(%s) already exists", name, accountName) } </ins> return nil }

return nil, fmt.Errorf("%s does not support block volume provisioning", a.plugin.GetPluginName()) } <del> var sku, resourceGroup, location, account string </del> <ins> var sku, resourceGroup, location, account, shareName string </ins> <del> // File share name has a length limit of 63, and it cannot contain two consecutive '-'s. name := util.GenerateVolumeName(a.options.ClusterName, a.options.PVName, 63) name = strings.Replace(name, "--", "-", -1) </del> capacity := a.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)] requestGiB := int(volumehelpers.RoundUpToGiB(capacity)) secretNamespace := a.options.PVC.Namespace

secretNamespace = v case "resourcegroup": resourceGroup = v <ins> case "sharename": shareName = v </ins> default: return nil, fmt.Errorf("invalid option %q for volume plugin %s", k, a.plugin.GetPluginName()) }

return nil, fmt.Errorf("claim.Spec.Selector is not supported for dynamic provisioning on Azure file") } <ins> if shareName == "" { // File share name has a length limit of 63, and it cannot contain two consecutive '-'s. name := util.GenerateVolumeName(a.options.ClusterName, a.options.PVName, 63) shareName = strings.Replace(name, "--", "-", -1) } </ins> // when use azure file premium, account kind should be specified as FileStorage accountKind := string(storage.StorageV2) if strings.HasPrefix(strings.ToLower(sku), "premium") { accountKind = string(storage.FileStorage) } <del> account, key, err := a.azureProvider.CreateFileShare(name, account, sku, accountKind, resourceGroup, location, requestGiB) </del> <ins> account, key, err := a.azureProvider.CreateFileShare(shareName, account, sku, accountKind, resourceGroup, location, requestGiB) </ins> if err != nil { return nil, err }

PersistentVolumeSource: v1.PersistentVolumeSource{ AzureFile: &v1.AzureFilePersistentVolumeSource{ SecretName:      secretName, <del> ShareName:       name, </del> <ins> ShareName:       shareName, </ins> SecretNamespace: &secretNamespace, }, },
Change:
Repro:
/assign
GitHub didn't allow me to assign the following users: changyaowei. 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 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
this test case was introduced by . Could you verify it ? cc
I believe this is fixed by - which is waiting on a merge. I'll re-ping the assigned reviewer :)
I already fixed it in , it waiting to be merged.

Discussion:
}}, } pleg.relist() <del> // event channel is full, discard events expected = []*PodLifecycleEvent{ </del> <ins> allEvents := []*PodLifecycleEvent{ </ins> {ID: "1234", Type: ContainerRemoved, Data: "c1"}, {ID: "1234", Type: ContainerDied, Data: "c2"}, {ID: "1234", Type: ContainerStarted, Data: "c3"}, {ID: "4567", Type: ContainerRemoved, Data: "c1"}, <ins> {ID: "4567", Type: ContainerStarted, Data: "c4"}, </ins> } <ins> // event channel is full, discard events </ins> actual = getEventsFromChannel(ch) <del> verifyEvents(t, expected, actual) </del> <ins> assert.True(t, len(actual) == 4, "channel length should be 4") assert.Subsetf(t, allEvents, actual, "actual events should in all events") </ins> } func TestDetectingContainerDeaths(t *testing.T) {
Change:
/assign
/sig testing
Switching to running bazel in does not change the result
Looks like this has to do with needing a privileged container

Discussion:
platform( name = "rbe_with_network", parents = ["@rbe_default//config:platform"], <ins> # https://cloud.google.com/remote-build-execution/docs/remote-execution-environment#remote_execution_properties </ins> remote_execution_properties = """ properties: { name: "dockerNetwork" value: "standard" } <ins> properties: { name: "dockerPrivileged" value: "true" } </ins> {PARENT_REMOTE_EXECUTION_PROPERTIES} """, )
Change:
Repro: Errors tend to look something like this:
should demonstrate that this package's unit tests are flaky, see initial comments /assign
/assign Looks like a race in probe watcher stop?
GitHub didn't allow me to assign the following users: chardch. 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 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
The probe watcher stop is explicitly setup as a synchronization point. We expect all goroutines started by that module to finish at most 11s after stop is called (10s is the timeout for a socket). I'll take a look at trying to reproduce this and getting the klogs that the pluginwatcher should output.
No longer seem able to repro this:
I have also seen in my test environment, I will try reproducing this and let you know how it goes!
no luck in reproducing:
Many time I've seen this test is failing with older version golang compare to new one.! like or
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
Same problem here.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
platform( name = "rbe_with_network", parents = ["@rbe_default//config:platform"], <ins> # https://cloud.google.com/remote-build-execution/docs/remote-execution-environment#remote_execution_properties </ins> remote_execution_properties = """ properties: { name: "dockerNetwork" value: "standard" } <ins> properties: { name: "dockerPrivileged" value: "true" } </ins> {PARENT_REMOTE_EXECUTION_PROPERTIES} """, )
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gci-gce-scalability and all other gce performance tests Which test(s) are failing: List resource fails. Since when has it been failing: Run . 02:57 PDT 04/25/2019 Testgrid link: Reason for failure: After 4th attempt the script fails. Anything else we need to know:
/sig testing
The error is returned by the
IIUC the problem is cause by call. When there is no filter argument passed (${3}) there is call executed. The "" causes unrecognized arguments error.
/assign

Discussion:
local attempt=1 local result="" while true; do <del> if result=$(gcloud "${group}" "${resource}" list --project="${PROJECT}" "${filter:+--filter="$filter"}" "${@:4}"); then </del> <ins> if result=$(gcloud "${group}" "${resource}" list --project="${PROJECT}" ${filter:+--filter="$filter"} "${@:4}"); then </ins> if [[ -n "${GREP_REGEX:-}" ]]; then result=$(echo "${result}" | grep "${GREP_REGEX}" || true) fi
Change:
<!-- 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: (as documented ) reports this: But certificates are actually stored in a Secret (not ConfigMap) by that name and in that namespace. The message printed by kubeadm should be changed accordingly. /sig cluster-lifecycle Environment: Kubernetes version (use ): 1.14.1 Cloud provider or hardware configuration: n/a OS (e.g: ): Debian Install tools: kubeadm

Discussion:
//UploadCerts save certs needs to join a new control-plane on kubeadm-certs sercret. func UploadCerts(client clientset.Interface, cfg *kubeadmapi.InitConfiguration, key string) error { <del> fmt.Printf("[upload-certs] Storing the certificates in ConfigMap %q in the %q Namespacen", kubeadmconstants.KubeadmCertsSecret, metav1.NamespaceSystem) </del> <ins> fmt.Printf("[upload-certs] Storing the certificates in Secret %q in the %q Namespacen", kubeadmconstants.KubeadmCertsSecret, metav1.NamespaceSystem) </ins> decodedKey, err := hex.DecodeString(key) if err != nil { return err
Change:
What happened: What you expected to happen: should not fail because of it's response size. How to reproduce it (as minimally and precisely as possible): N/A. Anything else we need to know?: Run batches through Argo workflow, but I don't think it's specific to the workloads. Environment: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: Amazon Linux 2 OS (e.g: ):Kernel (e.g. ): <br<brMy question is: limit is 8 MB. limit is 16 MB. 's the difference between and ? is for Docker, and is for containerd? Can somebody help understand the difference? does have difference limit than ? I think we should give them the same limits. /cc
/sig node
+1 to make it the same. as reviewers mentioned, it's a temporary thing as the right way to fix it is to have some pagination which is not available currently
Thanks for the guidance - putting out a pr to bump the size rn.

Discussion:
"k8s.io/kubernetes/pkg/kubelet/util" ) <del> // maxMsgSize use 8MB as the default message size limit. </del> <ins> // maxMsgSize use 16MB as the default message size limit. </ins> // grpc library default is 4MB <del> const maxMsgSize = 1024 * 1024 * 8 </del> <ins> const maxMsgSize = 1024 * 1024 * 16 </ins> // DockerServer is the grpc server of dockershim. type DockerServer struct {
Change:
<!-- 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: RollingUpdate daemonset got stucked, leaves a few pod not updated. Daemonset's status are as follows: What you expected to happen: All pods managed by daemonset upgrade succeed. How to reproduce it (as minimally and precisely as possible): minReadySeconds for deamonset -controller's clock time is a little slower than node. Anything else we need to know?: related issue and pr Environment: the latest k8s version also has this bug
/sig apps
/assign
Please rename our production daemonset name to "foo-daemonset"

Discussion:
return fmt.Errorf("error storing status for daemon set %#v: %v", ds, err) } <ins> // Resync the DaemonSet after MinReadySeconds as a last line of defense to guard against clock-skew. if ds.Spec.MinReadySeconds > 0 && numberReady != numberAvailable { dsc.enqueueDaemonSetAfter(ds, time.Duration(ds.Spec.MinReadySeconds)*time.Second) } </ins> return nil }
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: () Since when has it been failing: Failing 4/27. Testgrid link: Reason for failure: /kind failing-test /priority critical-urgent /milestone v1.15 /sig cluster-lifecycle /cc
cc
testing locally
PR sent: feel free to LGTM.
Thank you very much and for jumping on this so quickly

Discussion:
srcs = [ "arguments_test.go", "cgroupdriver_test.go", <del> "chroot_test.go", </del> "endpoint_test.go", "error_test.go", "marshal_test.go",

<del> // +build !windows /* Copyright 2018 The Kubernetes Authors. 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. */ package util import ( "os" "os/exec" "path/filepath" "strings" "testing" ) // Can't just call Chroot() because it will affect other tests in the // same process.  Golang makes it hard to just call fork(), so instead // we exec ourselves again, and run the test in the new subprocess. func testChrootReal(t *testing.T) { testfile := filepath.FromSlash("/" + filepath.Base(os.Args[0])) dir := filepath.Dir(os.Args[0]) if dir == "." { t.Skip("skipping: running test at root somehow") } if err := Chroot(dir); err != nil { if strings.Contains(err.Error(), "operation not permitted") { t.Skip("skipping: insufficient permissions to chroot") } t.Fatalf("chroot error: %v", err) } // All file access should now be relative to `dir` if _, err := os.Stat(testfile); err != nil { t.Errorf("Expected file %q to exist, but got %v", testfile, err) } } func TestChroot(t *testing.T) { if os.Getenv("GO_TEST_CHROOT_FOR_REALZ") == "1" { testChrootReal(t) return } cmd := exec.Command(os.Args[0], "-test.v", "-test.run=TestChroot") cmd.Env = []string{"GO_TEST_CHROOT_FOR_REALZ=1"} out, err := cmd.Output() t.Logf("subprocess output:n%s", out) if err != nil { t.Errorf("subprocess error: %v", err) } } </del>
Change:
What happened: When updating to 1.15 in IPVS mode, kube-proxy fails to start What you expected to happen: kube-proxy updates ok How to reproduce it (as minimally and precisely as possible): Deploy kube-proxy <1.15 in ipvs mode and update to 1.15 Anything else we need to know?: Error message in kube-proxy: I think the reason is the change of ipset type (bitmap to hash) in PR The 2 sets that creates the problem are: - Removing the sets manually works but is not a great solution for in-place updates. I think we should fix this before the 1.15 release (not sure what the best approach is: delete the set if it exists with the wrong type? Use a different name to avoid the collision?) Environment: Kubernetes version (use ): 1.14 =1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): ubuntu 18.04 Kernel (e.g. ): 4.4 /sig network /area ipvs /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by ‍
Great catch! Looks like a breaking change. One solution like you mentioned is to add support for replacing ipsets in if a similar ipset already exists? Thoughts
I noticed we pass in for ipsets but that only checks for identical ipset types. Maybe needs to be smarter and do a full diff
This could work as well
Opened a fix for it here , let's chat there :)
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved

Discussion:
kubeNodePortLocalSetUDPComment = "Kubernetes nodeport UDP port with externalTrafficPolicy=local" kubeNodePortLocalSetUDP        = "KUBE-NODE-PORT-LOCAL-UDP" <del> kubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose" kubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP" </del> <ins> // This ipset is no longer active but still used in previous versions. // DO NOT create an ipset using this name legacyKubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose" legacyKubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP" </ins> <del> kubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local" kubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP" </del> <ins> // This ipset is no longer active but still used in previous versions. // DO NOT create an ipset using this name legacyKubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local" legacyKubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP" kubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose with type 'hash ip:port'" kubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP-HASH" kubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local with type 'hash ip:port'" kubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP-HASH" </ins> ) // IPSetVersioner can query the current ipset version.
Change:
What happened: The history limit in the describe display has the incorrect number What you expected to happen: The history limit should show the default limit (3) How to reproduce it (as minimally and precisely as possible): Add a cronjob with default history limit settings and run Anything else we need to know?: Environment: Kubernetes version (use ): $ kubectl version Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-04-08T17:02:58Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g: ): Ubuntu 18.04.2 Kernel (e.g. ): Linux bionic-vm 4.15.0-48-generic -Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeam Network plugin and version (if this is a network-related bug): Others:
/sig cli
/assign

Discussion:
w.Write(LEVEL_0, "Concurrency Policy:t%sn", cronJob.Spec.ConcurrencyPolicy) w.Write(LEVEL_0, "Suspend:t%sn", printBoolPtr(cronJob.Spec.Suspend)) if cronJob.Spec.SuccessfulJobsHistoryLimit != nil { <del> w.Write(LEVEL_0, "Successful Job History Limit:t%dn", cronJob.Spec.SuccessfulJobsHistoryLimit) </del> <ins> w.Write(LEVEL_0, "Successful Job History Limit:t%dn", *cronJob.Spec.SuccessfulJobsHistoryLimit) </ins> } else { w.Write(LEVEL_0, "Successful Job History Limit:t<unset>n") }
Change:
What happened: Minor issue with the current source code in : The error message "Could not attach disk: Timeout after 10s" includes the verbatim string constant "10" (appears two times in adjacent rows), but the call to in the preceding if statement refers to the Go constant (currently set to 10) instead. The strings for the error messages should refer to (i.e. print) the same Go constant to guarantee that they always stay in sync. Kubernetes version: current master branch on GitHub /sig storage
/assign

Discussion:
} if exist := waitForPathToExist(&devicePath, multipathDeviceTimeout, iscsiTransport); !exist { <del> klog.Errorf("Could not attach disk: Timeout after 10s") </del> <ins> klog.Errorf("Could not attach disk: Timeout after %ds", multipathDeviceTimeout) </ins> // update last error <del> lastErr = fmt.Errorf("Could not attach disk: Timeout after 10s") </del> <ins> lastErr = fmt.Errorf("Could not attach disk: Timeout after %ds", multipathDeviceTimeout) </ins> continue } else { devicePaths[tp] = devicePath