jiebi/CodeConvo huggingface dataset:
Change:
<ins> ### Warning: Only use this plugin  in Read Only mode. There is currently [a critical bug](https://github.com/GoogleCloudPlatform/kubernetes/issues/7317) that deletes your data when used in Read/Write mode. </ins> ## Glusterfs [Glusterfs](http://www.gluster.org) is an open source scale-out filesystem. These examples provide information about how to allow containers use Glusterfs volumes.

Discussion:
a set of endpoints to your GlusterFS cluster. Example a pod that uses the GlusterFS Volume Plugin in ReadWrite Mode (readonly=false) to mount a particular GlusterFS volume. Example the pod is running the contents of that GlusterFS Volume and see that your files exist. the pod - "kubectl delete pod glusterfs" the contents of your GlusterFS Volume and see that your files no longer exist. Environment: GlusterFS - verified with GlusterFS running on either Fedora 21 or RHEL 6.5. Kubernetes - running on Fedora 21 Note: This issue does not occur if the GlusterFS Volume Plugin is in ReadOnly Mode (readonly=true)
heh, this is why I wanted to refactor the mount/unmount/cleanup code - get it right once :)
cc
I went back to commit (the original merge for glusterfs volume) and couldn't replicate the bug. after updating to HEAD i could replicate. so something changed between first merge and HEAD causing issue.
It's caused by commit : This is called before unmounting of volumes, which are mounted somewhere into . why RemoveAll()? It was not there before your commit.
Fixed in PR
Sorry for injecting the bug. I was thinking of moving volume & pod dir cleanup into the function, but it didn't pan out, and the code was left unintentionally. Thanks for fixing it! The logic still seems strange in some cases. looks at the containers we failed to kill, and skip cleaning up volumes associated with them. But doesn't look at the those containers and would just go ahead and remove the directories for all the pods that we supposedly killed. I will file and issue later.
Is this fixed now? If so, please close. , Yu-Ju Hong wrote:
Change:
err := kl.syncPod(pod, dockerContainers) if err != nil { glog.Errorf("Error syncing pod, skipping: %v", err) <ins> record.Eventf(pod, "", "failedSync", "Error syncing pod, skipping: %v", err) </ins> } }) }

Discussion:
During a PD testing, I created a pod, and found it has a trouble to be started for a half hour, but events show it properly started: $ get pods Running: cluster/../cluster/gce/../../output/dockerized/bin/linux/amd64/kubectl get pods POD CONTAINER(S) IMAGE(S) HOST LABELS STATUS testpd testpd kubernetes/pause kubernetes-minion- <nonePending $ get events | grep testpd Running: cluster/../cluster/gce/../../output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 The issue might be missing some key events or events are misleading. Looking into it.
Change:
// If a revision annotation already existed and this replica set was updated with a new revision // then that means we are rolling back to this replica set. We need to preserve the old revisions // for historical information. <del> if ok && annotationChanged { </del> <ins> if ok && oldRevisionInt < newRevisionInt { </ins> revisionHistoryAnnotation := newRS.Annotations[RevisionHistoryAnnotation] oldRevisions := strings.Split(revisionHistoryAnnotation, ",") if len(oldRevisions[0]) == 0 { newRS.Annotations[RevisionHistoryAnnotation] = oldRevision } else { <del> oldRevisions = append(oldRevisions, oldRevision) newRS.Annotations[RevisionHistoryAnnotation] = strings.Join(oldRevisions, ",") </del> <ins> totalLen := len(revisionHistoryAnnotation) + len(oldRevision) + 1 // index for the starting position in oldRevisions start := 0 for totalLen > revHistoryLimitInChars && start < len(oldRevisions) { totalLen = totalLen - len(oldRevisions[start]) - 1 start++ } if totalLen <= revHistoryLimitInChars { oldRevisions = append(oldRevisions[start:], oldRevision) newRS.Annotations[RevisionHistoryAnnotation] = strings.Join(oldRevisions, ",") } else { klog.Warningf("Not appending revision due to length limit of %v reached", revHistoryLimitInChars) } </ins> } } // If the new replica set is about to be created, we need to add replica annotations to it.

Discussion:
What happened: We created a Deployment and continuously updated an annotation on it periodically for a week. Eventually, we noticed errors in the controller-manager logs due to the annotation growing too large. Example annotations: controller-manager error: What you expected to happen: that do not change the revision number should not be to the revision history. revision history should be capped at a fixed number of elements, it should not be possible to have unbounded growth for Deployments that are frequently updated. How to reproduce it (as minimally and precisely as possible): a Deployment modify an annotation on it and note that the annotation gets the same number appended every time. Environment: Kubernetes version (use ):
/sig scalability Not 100% sure where this one fits, I couldn't determine which group owns the Deployment/ReplicaSet controllers, but this is a scalability problem
/sig apps
Agree with these, and if the limit is hit, the beginning of the history can be removed.
/assign
Change:
// the request entity is too large. // It supports wrapped errors. func IsRequestEntityTooLargeError(err error) bool { <del> if ReasonForError(err) == metav1.StatusReasonRequestEntityTooLarge { </del> <ins> reason, code := reasonAndCodeForError(err) if reason == metav1.StatusReasonRequestEntityTooLarge { </ins> return true } <del> if status := APIStatus(nil); errors.As(err, &status) { return status.Status().Code == http.StatusRequestEntityTooLarge </del> <ins> // IsRequestEntityTooLargeError's checking of code predates the checking of // the code in the other Is* functions. In order to maintain backward // compatibility, this does not check that the reason is unknown. if code == http.StatusRequestEntityTooLarge { return true </ins> } return false }

Discussion:
Checked a method error using when the error was caused by a validating webhook that returns a 403 response. In this particular case, the error was generated from a validating webhook implemented with controller-runtime that returns controller-runtime's response. to return true. returned false Many (but not all) of the other family of functions in suffer the same kind of problem. I have changes ready to submit in a PR if we can get agreement that this is a problem and that it should be fixed in the functions that ought to check the of an erorr value that is or wraps an Kubernetes version (use ): 19.3 for the server
/sig api-machinery
are you going to send a PR for this? The issue description looks reasonable. /triage accepted
Thanks, PR is submitted.
/assign
Change:
cmdutil.AddDryRunFlag(cmd) cmd.Flags().StringVar(&o.ClusterRole, "clusterrole", "", i18n.T("ClusterRole this ClusterRoleBinding should reference")) cmd.MarkFlagRequired("clusterrole") <del> cmd.Flags().StringArrayVar(&o.Users, "user", o.Users, "Usernames to bind to the clusterrole") cmd.Flags().StringArrayVar(&o.Groups, "group", o.Groups, "Groups to bind to the clusterrole") cmd.Flags().StringArrayVar(&o.ServiceAccounts, "serviceaccount", o.ServiceAccounts, "Service accounts to bind to the clusterrole, in the format <namespace>:<name>") </del> <ins> cmd.Flags().StringArrayVar(&o.Users, "user", o.Users, "Usernames to bind to the clusterrole. The flag can be repeated to add multiple users.") cmd.Flags().StringArrayVar(&o.Groups, "group", o.Groups, "Groups to bind to the clusterrole. The flag can be repeated to add multiple groups.") cmd.Flags().StringArrayVar(&o.ServiceAccounts, "serviceaccount", o.ServiceAccounts, "Service accounts to bind to the clusterrole, in the format <namespace>:<name>. The flag can be repeated to add multiple service accounts.") </ins> cmdutil.AddFieldManagerFlagVar(cmd, &o.FieldManager, "kubectl-create") // Completion for relevant flags

Discussion:
I'm not sure whether this is the documentation being unclear, or a bug with kubectl itself but I suspect the former. Given this help page I expected to be able to use Instead I got the following error To get the same output as defining the flag twice aka and should give the same output, or the help page shouldn't list as the parameter type for --serviceaccount No response <details</details<detailsN/A </details<details</details<details</details<detailsarchitecture: amd64 bootID: -c6dc-40bb-9485- containerRuntimeVersion: containerd://1.5.5 kernelVersion: 5.4.0-88-generic kubeProxyVersion: v1.23.1 kubeletVersion: v1.23.1 </details<details</details
/sig cli
the flag can be specified multiple times, or (I think) as a comma-separated list. agree the notation is confusing... I think that's how cobra prints the default value (which is an empty list)
Hi I have tried and confirmed that it works with multiple flags: But for the comma-separated list, doesn't work. Kubectl version: v1.23.3 and k8s version v1.23.3
The same update for rolebinding: Should we write like this(same for clusterrolebinding):
Thanks for the investigation, another approach that might help is adding an example with the comma separated service accounts in the examples section. I do wonder if there's a clearer representation that could be output by cobra, to make it clear what the behaviour should be...?
Hi, I think adding the example is good so that users who reference this document get the proper information. but there is already mention of how to this flag with create command under the usage section: What do you suggest
in the specific flag help, we can mention the flag can be repeated to add multiple subjects
+1 I will update this. /assign
This sounds good to me, might be worth doing the same for other places that use the same behaviour?
Sure I will do that.
I have fixed it here: PTAL!
/triage accepted
Change:
// ExternalID is a test-spy implementation of Instances.ExternalID. // It adds an entry "external-id" into the internal method call record. <ins> // It returns an external id to the mapped instance name, if not found, it will return "ext-{instance}" </ins> func (f *FakeCloud) ExternalID(instance string) (string, error) { f.addCall("external-id") <del> return f.ExtID, f.Err </del> <ins> return f.ExtID[instance], f.Err </ins> } // List is a test-spy implementation of Instances.List.

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).
Change:
NS="${8:-$NS}"          # namespace NODE_PORT="${9:-$NODE_PORT}" #nodePort, see fe-s.json echo "Running w/ args: kubectl $kubectl version $VERSION sec $_SECONDS fe $FE lg $LG slave $SLAVE test = $TEST, NAMESPACE = $NS, NODE_PORT = $NODE_PORT" <ins> function create_ns { case "$NS" in "default" ) ;; "kube-system" ) ;; * ) cat << EOF > ns.json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "$NS" } } EOF $kubectl create -f ns.json esac } </ins> function create { cat << EOF > fe-rc.json

Discussion:
During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.
Change:
// can't reliably simulate periodic sync of volumes/claims - it would be // either very timing-sensitive or slow to wait for real periodic sync. func TestControllerSync(t *testing.T) { <ins> expectedChanges := []int{1, 4, 1, 1} </ins> tests := []controllerTest{ // [Unit test set 5] - controller tests. // We test the controller as if

Discussion:
Not many details in the logs: FAIL 2.721s
I ran tests a few times against recent master but couldn't see this, could it be an edgy case?
i'll look at it
should help a lot, still there will be a short window where the test could get wrong. Patch will follow when is merged.
Today I saw a very similar error to the one reported in , but seeing as that was closed as a dupe of this, adding details here:
this looks like something new. Let's keep this issue open for this unit test flake: I filled for integration test flake you reported.
Change:
runtime_config="--runtime-config=${RUNTIME_CONFIG}" fi <ins> # Let the API server pick a default address when API_HOST # is set to 127.0.0.1 advertise_address="" if [[ "${API_HOST}" != "127.0.0.1" ]]; then advertise_address="--advertise_address=${API_HOST}" fi </ins> APISERVER_LOG=/tmp/kube-apiserver.log sudo -E "${GO_OUT}/hyperkube" apiserver ${priv_arg} ${runtime_config} <ins> ${advertise_address}  </ins> --v=${LOG_LEVEL}  --cert-dir="${CERT_DIR}"  --service-account-key-file="${SERVICE_ACCOUNT_KEY}" 

Discussion:
seems to have broken the kubernetes service when using : With this patch: Without it: Tested with v 1.3.2.
Looks like we don't like explicitly don't want to allow 127.0.0.1 loopback address here -
Change:
return false } <del> func findRule(rules []network.LoadBalancingRule, rule network.LoadBalancingRule) bool { </del> <ins> func findRule(rules []network.LoadBalancingRule, rule network.LoadBalancingRule, wantLB bool) bool { </ins> for _, existingRule := range rules { if strings.EqualFold(to.String(existingRule.Name), to.String(rule.Name)) && <del> equalLoadBalancingRulePropertiesFormat(existingRule.LoadBalancingRulePropertiesFormat, rule.LoadBalancingRulePropertiesFormat) { </del> <ins> equalLoadBalancingRulePropertiesFormat(existingRule.LoadBalancingRulePropertiesFormat, rule.LoadBalancingRulePropertiesFormat, wantLB) { </ins> return true } }

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: When the Idle Timeout annotation was set to "3" which isn't a supported case, kube-controller-manager is stuck in deleting Azure LB. New service with the same name couldn't be created again even without the annotation. What you expected to happen: New service should be created successfully. 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: Others: /sig azure /kind bug
/assign Since I'm seeing this on some of our clusters
/priority important-soon
Thanks
- The problem here seems that when we want to call (when processing a delete event) it reconciles the loadbalancer which in turn tries to get the idleTimeout, resulting in an error. one of the strategies is to still construct our diff in case of a delete and exercise the code path at the end. This basically translate into ignoring the error when getting idleTimeout and excluding it from finding if the rule is dirty or not when we are . toughts ? Generally speaking, whenever we update a loadbalancer with unsupported values on annotations, ensuring load balancer will fail resulting in an un-cleaned LB, this is a cross-provider issue. /sig cloud-provider cc
cc
lgtm. the delete operation should continue to do cleanup job even some wrong options are provided from users.
Change:
config := e2enetwork.NewNetworkingTestConfig(f, false, false) ginkgo.By(fmt.Sprintf("dialing(http) %v --> %v:%v (config.clusterIP)", config.TestContainerPod.Name, config.ClusterIP, e2enetwork.ClusterHTTPPort)) message := strings.Repeat("42", 1000) <del> config.DialEchoFromTestContainer("http", config.ClusterIP, e2enetwork.ClusterHTTPPort, config.MaxTries, 0, message) </del> <ins> err := config.DialEchoFromTestContainer("http", config.ClusterIP, e2enetwork.ClusterHTTPPort, config.MaxTries, 0, message) if err != nil { framework.Failf("failed dialing endpoint, %v", err) } </ins> }) ginkgo.It("should be able to handle large requests: udp", func() { config := e2enetwork.NewNetworkingTestConfig(f, false, false) ginkgo.By(fmt.Sprintf("dialing(udp) %v --> %v:%v (config.clusterIP)", config.TestContainerPod.Name, config.ClusterIP, e2enetwork.ClusterUDPPort)) message := "n" + strings.Repeat("o", 1999) <del> config.DialEchoFromTestContainer("udp", config.ClusterIP, e2enetwork.ClusterUDPPort, config.MaxTries, 0, message) </del> <ins> err := config.DialEchoFromTestContainer("udp", config.ClusterIP, e2enetwork.ClusterUDPPort, config.MaxTries, 0, message) if err != nil { framework.Failf("failed dialing endpoint, %v", err) } </ins> }) })

Discussion:
What would you like to be : Right now we poll one node at a time for intra-pod tests. We ultimately fail a test if any one node is unreachable. If we instead polled all nodes, multiple times, and collected the number of times a node was unreachable, this would tell us what % of nodes on the cluster were broken, rather then just telling us the first node that was broken. not break the testing contract (were still verifying intra-pod connectivity, just doing so in a way that gives us holistic cluster info) Why is this needed: I described why this would make triage alot easier, and in general make it easier to see why tests are failing, here ... i'll collect a little more data on this to justify the decision .... as this is a conformance test so the bar for modification is higher (even if the test itself isnt changing) then regular tests.
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
package api import ( <del> "github.com/fsouza/go-dockerclient" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" <ins> "github.com/fsouza/go-dockerclient" </ins> ) // Common string formats

Discussion:
What would you like to be : We'd like to have the Prometheus stack () running in our scalability tests. Why is this needed: There are couple of reasons: will simplify writing SLI assertions/tests that are based on metrics not necessarily exported on master. Some examples here are the new In-Cluster Network Programming Latency SLI (exported in kube-proxy) or soon to be implemented RTT SLI where the metric will be exported in regular pods (probes). With Prometheus stack, collecting and aggregating such metrics is very simple. -prometheus provides many useful metrics about the state of the cluster, such metrics might be invaluable when debugging scalability test failures. mimics what customers do in their cluster, making the test setup more realistic.
/sig scalability
/assign
The GCE 5K Node Performance test with enabled Prometheus completed successfully. We can enable Prometheus in all tests.
Looks like kubemark-500 has some issue, test fails often with Kubemark-5000 also failed once with Will disable Prometheus in kubemark, will work on fixing it when I'm back from my vacation.
For the first kind of the failure that kubemark-500 suffered from, i.e. the root cause is Looks like the token for the "prometheus-operator" service account was not ready, as we can see in the logs it was created after the POST to create the servicemonitor was called.
It looks like the second failure (kubemark-5000) was caused by the prometheus-k8s pods not scheduled by the kube-scheduler. This is strange but may be related to other issues we had. Hard to investigate what really happened there, will leave it for now. Will re-enable prometheus tomorrow and will see if it happens again.
Closing, as this is basically done in a minimal version. Other improvements will be tracked in separate issues. /close
Closing this issue. <detailsIn response to : Closing, as this is basically done in a minimal version. 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