jiebi/CodeConvo huggingface dataset:
Change:
// Worst case analysis: 15 failures, each taking 1 minute to // run due to some slowness, 1 in 2^15 chance of happening, // causing test flake.  Should be very rare. <del> job := framework.NewTestJob("randomlySucceedOrFail", "rand-non-local", v1.RestartPolicyNever, parallelism, completions, nil, backoffLimit) </del> <ins> job := framework.NewTestJob("randomlySucceedOrFail", "rand-non-local", v1.RestartPolicyNever, parallelism, completions, nil, 999) </ins> job, err := framework.CreateJob(f.ClientSet, f.Namespace.Name, job) Expect(err).NotTo(HaveOccurred())

Discussion:
https://k8s- Failed: [] Job should run a job to completion when tasks sometimes fail and are not locally restarted {Kubernetes e2e suite} Previous issues for this test:
Meta issue:
This is not a problem with that particular test but a general problem mentioned in . Closing in favor of that.
/reopen this job seems to be one of the flakiest sig-apps jobs, both on and .
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen </details
/remove-priority backlog /priority important-soon
I'm hoping to get to this flake later this week, or Monday next week at latest.
Change:
return orderedPlugins } <ins> //Return names of plugins which are enabled by default func (a *AdmissionOptions) defaultEnabledPluginNames() []string { defaultOnPluginNames := []string{} for _, pluginName := range a.RecommendedPluginOrder { if !a.DefaultOffPlugins.Has(pluginName) { defaultOnPluginNames = append(defaultOnPluginNames, pluginName) } } return defaultOnPluginNames } </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: With the recent change to the way admission control plugins are handled the generated documentation doesn't provide a list of plugins that are enabled: REF: What you expected to happen: I expected to be able to determine what admission plugins are enabled on the apiserver. With the default enabled plugins enumerated I can determine that by evaluating the list against the explicitly and and admission control plugins. 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:
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
/cc
/assign
Change:
describeRequest.Filters = s.addFilters(filters) actualGroups, err := s.ec2.DescribeSecurityGroups(describeRequest) if err != nil { <del> return fmt.Errorf("error querying security groups: %v", err) </del> <ins> return fmt.Errorf("error querying security groups for ELB: %v", err) </ins> } taggedSecurityGroups, err := s.getTaggedSecurityGroups()

Discussion:
From Slack, we got a report that "my service controller is trying to delete a ELB ( im running k8s in ews ) thats is not there, and for that reason its failing over and over again with the message " It turns out the user had deleted the ELB manually. We should tolerate this better.
I think this was actually caused by a failure to tag the cluster, which triggered another bug where we can't pass an empty filters list to the AWS API
Change:
"my-cluster": {Server: "https://192.168.0.1:3434"}, }, Contexts: map[string]*clientcmdapi.Context{ <del> "minikube":  {AuthInfo: "minikube", Cluster: "minikube"}, "my-cluser": {AuthInfo: "mu-cluster", Cluster: "my-cluster"}, </del> <ins> "minikube":   {AuthInfo: "minikube", Cluster: "minikube"}, "my-cluster": {AuthInfo: "mu-cluster", Cluster: "my-cluster"}, </ins> }, CurrentContext: "minikube", AuthInfos: map[string]*clientcmdapi.AuthInfo{ <del> "minikube":  {Token: "minikube-token"}, "my-cluser": {Token: "minikube-token"}, </del> <ins> "minikube":   {Token: "minikube-token"}, "mu-cluster": {Token: "minikube-token"}, </ins> }, } test := viewClusterTest{ description: "Testing for kubectl config view", config:      conf, <del> flags:       []string{}, </del> expected: `apiVersion: v1 clusters: - cluster:

Discussion:
/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign Filed
Change:
RUNNERIMAGE?=gcr.io/distroless/static:latest <ins> QEMUVERSION?=5.2.0-2 </ins> build: # Explicitly copy files to the temp directory $(BIN_INSTALL) migrate-if-needed.sh $(TEMP_DIR)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:
Change:
BeforeEach(func() { setupStorageClass(config, &waitMode) <del> for _, node := range config.nodes { </del> <ins> for i, node := range config.nodes { </ins> By(fmt.Sprintf("Setting up %d local volumes on node %q", volsPerNode, node.Name)) <del> allLocalVolumes[node.Name] = setupLocalVolumes(config, volType, &node, volsPerNode) </del> <ins> allLocalVolumes[node.Name] = setupLocalVolumes(config, volType, &config.nodes[i], volsPerNode) </ins> } By(fmt.Sprintf("Create %d PVs", volsPerNode*len(config.nodes))) var err error

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-serial Which test(s) are failing: [sig-storage] PersistentVolumes-local Stress with local volumes [Serial] should be able to process many pods and reuse local volumes Since when has it been failing: since introduction Testgrid link: https://k8s- Reason for failure: Anything else we need to know:
/assign
/reopen 1 failure out of recent 4 builds since is merged, will make it stable
Reopened this issue. <detailsIn response to : /reopen 1 failure out of 4 builds since is merged, will make it stable 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 failure is because kubelet is restarted serval times during testing. fail time of test: Note that after , the rest 3 pods cannot finish. This is because kubelet is restarted serval times in this period of time. Output of : The rest 3 jobs was assigned to this node, it cannot finished because kubelet is restarted repeatedly. Because all tests in this job is run serially. I'm not sure what caused kubelet to restart during this test is running. kubelet.service is configured with following configurations: With , kubelet may be restarted by clean/unclean signal, exit code or watchdog, timeout. And may kill it when it failed to , here is kubelet-
I guess these kubelet restarts are not expected, but fixing it is beyond my ability. One workaround is to increase timeout to tolerate them, what do you think? Because we check pod conditions periodically, it will not slow down test.
Maybe we need to get some help from node team to figure out why kubelet is restarting. cc
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
This test has not flaked in almost 2 weeks. /close
Closing this issue. <detailsIn response to : This test has not flaked in almost 2 weeks. /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
Change:
# Clean out any old releases rm -rf "${RELEASE_DIR}" mkdir -p "${RELEASE_DIR}" <del> kube::release::package_client_tarballs kube::release::package_server_tarballs kube::release::package_salt_tarball kube::release::package_test_tarball kube::release::package_full_tarball </del> <ins> kube::release::package_client_tarballs & kube::release::package_server_tarballs & kube::release::package_salt_tarball & wait || { kube::log::error "previous tarball phase failed"; return 1; } kube::release::package_full_tarball & # _full depends on all the previous phases kube::release::package_test_tarball & # _test doesn't depend on anything wait || { kube::log::error "previous tarball phase failed"; return 1; } </ins> } # Package up all of the cross compiled clients.  Over time this should grow into

Discussion:
Filing for This code is wrong The local needs to be on a separate line from the command execution, and we need to be resilient to not existing on OS X, like:
For once I was actually watching the output of a build and noticed that I was seeing an error about md5sum not being found. I'm building on a mac using boot2docker. The short_hash function () works fine on my mac as md5 does exist.
Actually, I'm just going to fix this as a follow-on to .
Thank you!
Change:
return } <del> err := validateTestName(v.getDescription(at.Value)) </del> <ins> description := v.getDescription(at.Value) err := validateTestName(description) </ins> if err != nil { v.failf(at, err.Error()) return

Discussion:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. 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
Change:
# The resource manifest is expecting something like 'registry/kube-controller-manager:v1.2.3', no arch specified. local -r images=$(docker images --format "{{.Repository}}:{{.Tag}}" | egrep 'kube-apiserver|kube-controller-manager|kube-scheduler|kube-proxy' | grep amd64) for image in $images ; do <del> local -r manifest_name="${image/-amd64/}" </del> <ins> local manifest_name="${image/-amd64/}" </ins> if ! docker images --format "{{.Repository}}:{{.Tag}}" | grep -q ${manifest_name} ; then docker tag $image $manifest_name fi

Discussion:
The failure looks like this (example from ): Easy to recreate using the following snippet
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
cc
Change:
expectedPlugins: &v1beta2.Plugins{ Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ <ins> {Name: "Plugin1", Weight: pointer.Int32Ptr(1)}, {Name: "Plugin2", Weight: pointer.Int32Ptr(2)}, {Name: "Plugin3"}, }, }, }, }, { name: "RepeatedCustomPlugin", customPlugins: &v1beta2.Plugins{ Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ </ins> {Name: "Plugin1"}, {Name: "Plugin2", Weight: pointer.Int32Ptr(2)}, {Name: "Plugin3"}, <ins> {Name: "Plugin2", Weight: pointer.Int32Ptr(4)}, }, }, }, defaultPlugins: &v1beta2.Plugins{ Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ {Name: "Plugin1"}, {Name: "Plugin2"}, {Name: "Plugin3"}, }, }, }, expectedPlugins: &v1beta2.Plugins{ Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ {Name: "Plugin1"}, {Name: "Plugin2", Weight: pointer.Int32Ptr(4)}, {Name: "Plugin3"}, {Name: "Plugin2", Weight: pointer.Int32Ptr(2)}, </ins> }, }, },

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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
<del> The original file is https://github.com/kubernetes-csi/external-snapshotter/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-snapshotter/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>

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: In below README files, URLs are written. But these URL include version name(master, release-1.0, etc...) which are enclosed in <and not shown in md files. What you expected to happen: URL will be shown correctly.
/sig storage
/remove-kind bug /kind documentation
can I take it up, as there is no activity for some days?
I already posted PR, thanks.
Change:
} opts.AddFlags(pflag.CommandLine) <del> utilflag.InitFlags() </del> cmd.MarkFlagFilename("config", "yaml", "yml", "json")

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I pull the latest code, and run with below cmd. But the cluster is not up. And I notice the kube-, 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 ): GitCommit:"" Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cluster-lifecycle
/assign
Can you please try the fix above?
/assign
/unassign
your pr does not fix it yet? If not, I can help.
The fix from works for me! o/
ok, thanks
reopen , make less modifications.
sorry, i miss hyper...
Change:
# $4: value for variable 'cpulimit' # $5: pod name, which should be either etcd or etcd-events prepare_etcd_manifest() { <del> local host_name=$(hostname) local etcd_cluster="" local cluster_state="new" for host in $(echo "${INITIAL_ETCD_CLUSTER}" | tr "," "n"); do etcd_host="etcd-${host}=http://${host}:$3" if [[ -n "${etcd_cluster}" ]]; then etcd_cluster+="," cluster_state="existing" fi etcd_cluster+="${etcd_host}" done </del> etcd_temp_file="/tmp/$5" cp /home/kubernetes/kube-manifests/kubernetes/gci-trusty/etcd.manifest "${etcd_temp_file}" <del> remove_salt_config_comments "${etcd_temp_file}" </del> sed -i -e "s@{{ *suffix *}}@$1@g" "${etcd_temp_file}" sed -i -e "s@{{ *port *}}@$2@g" "${etcd_temp_file}" sed -i -e "s@{{ *server_port *}}@$3@g" "${etcd_temp_file}" sed -i -e "s@{{ *cpulimit *}}@"$4"@g" "${etcd_temp_file}" <del> sed -i -e "s@{{ *host_name *}}@$host_name@g" "${etcd_temp_file}" sed -i -e "s@{{ *etcd_cluster *}}@$etcd_cluster@g" "${etcd_temp_file}" sed -i -e "s@{{ *cluster_state *}}@$cluster_state@g" "${etcd_temp_file}" </del> # Replace the volume host path sed -i -e "s@/mnt/master-pd/var/etcd@/mnt/disks/master-pd/var/etcd@g" "${etcd_temp_file}" mv "${etcd_temp_file}" /etc/kubernetes/manifests

Discussion:
test grid: Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Additional Context:
/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
cc Do we want to keep this job and fix it, or do something different considering the debs/rpms efforts?
I think we should keep this job as long as we build packages for Google infra (those are using different specs then packages for OBS).
fixed it for debs: The corresponding RPM job is also faster now:
Change:
password = password insecure-flag = true datacenter = us-west <ins> vm-uuid = 1234 </ins> `)) if err != nil { t.Fatalf("Should succeed when a valid config is provided: %s", err)

Discussion:
What keywords did you search in Kubernetes issues before filing this one?: VMware, vSphere, IP, UUID BUG REPORT. Kubernetes version: Environment: Cloud provider or hardware configuration: VMware vSphere 6.5.0 OS : Debian GNU/Linux 8.7 (jessie) Kernel : Install tools: Kargo What happened: Some containers were launched on a node with a name containing the hostname of a different node and the does not retrieve the right node name : Here is retrieved instead of . When using the VSphere Cloud provider, the node name is retrieved from the function in Since this PR (), the node data are retrieved based on the IP address instead of the UUID. The function gets all the IP address and check if one of the IP on any interface matches a VM on vSphere. The problem is that the docker0 interface has the same IP on all the nodes (usually 172.17.0.1) and this IP is referenced into VMware. As this IP may be the first to appear in the it will match the first VM that vSphere gives with the function and this can be any VM running Docker on vSphere. Thus, the provider has a big chance to not get the informations for the VM it is running on, leading to an inconsistent state in the cluster (wrong pod name for example). Anything else we need to know: An idea would be to first retrieve the VM name with the function and if no results use the IP address (and add an exclusion to not use the interface). What do you think ? If you think this might be the right way to do, we can try to propose the PR. Thanks for your feedback.
Wow, this very much is a bad, bad bug. It was introduced by one of my colleagues here at HPE. It's made worse if you run multiple Kubernetes clusters in the same vSphere Datacenter. I'll send a PR upstream tomorrow to resolve this. I think it's best to go back to using dmidecode, but maybe someone from VMware ( or ?) has another suggestion? This would still require root access, but I can't think of a better way to get the machine's ID.
Related issue Will dig in more. For now instead of making it a value determined runtime the deployment framework should have root privileges and can populate it as part of the cloud config post VM creation.
is my colleague.

A little more info and a few ideas. I would also support going back to ` (still requires root though). We could also have the following logic: Get UUID and use it to get the VM Name with FindByUUID if possible, If not, get the hostname and use FindByDNSName, If still nothing is found, keep the current logic, excluding docker0 from the interfaces we examine. However, I agree with that getting this from the cloud config may be the best and most reliable solution.
I'm working on a patch right now that will do the following: Add a VMUUID field to the cloud config If VMUUID is not set, will use Error out if neither one is available
PR is - if someone would like to review :)
Change:
"github.com/stretchr/testify/assert" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> k8sRuntime "k8s.io/apimachinery/pkg/runtime" </ins> "k8s.io/apimachinery/pkg/util/diff" "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/apis/componentconfig" <ins> "k8s.io/kubernetes/pkg/apis/componentconfig/v1alpha1" </ins> "k8s.io/kubernetes/pkg/util" <ins> "k8s.io/kubernetes/pkg/util/configz" </ins> "k8s.io/kubernetes/pkg/util/iptables" )

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? is:issue is:open ipv6 Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): N/A, these are unit test changes in latest master Environment: Cloud provider or hardware configuration: Kubernetes container dev env on Ubuntu 16.04.1 OS (e.g. from /etc/os-release): Ubuntu 16.04.1 Kernel (e.g. ): 4.4.0-78-generic -Ubuntu x8664 GNU/Linux Install tools: Others: What happened: Upon inspection, no IPv6 test cases found in kubernetes/cmd/kube- What you expected to happen: Expect to see some IPv6 test cases exercised for kube-proxy server code (kubernetes/cmd/kube-). Also need some code coverage for negative conditions in How to reproduce it (as minimally and precisely as possible): Run unit tests in kubernetes/cmd/kube- Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig networking
/area ipv6
/sig network