jiebi/CodeConvo huggingface dataset:
Change:
syncLoopFrequency    = 10 * time.Second maxBackOffTolerance  = time.Duration(1.3 * float64(kubelet.MaxContainerBackOff)) podRetryPeriod       = 1 * time.Second <del> podRetryTimeout      = 1 * time.Minute </del> ) // testHostIP tests that a pod gets a host IP

Discussion:
pull-kubernetes-e2e-kind-ipv6 Pods should delete a collection of pods According to testgrid, March 18th Timeout in No response /sig node
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
Looking at The test is here - It creates 3 pods which go into Failed phase and then expects them to within . Looking at failure in the build-log, there were three pods created, , , . did not get deleted from the API-server within the 1 minute timeout causing the test to fail. From the build-log, the test starts checking for all the pods to be deleted at: So the test expected all the pods to be deleted at 1 minute + 18:35:03 = 18:36:03 Looking at the logs of which landed on : DELETE was sent at landed on DELETE was sent at which is ~20 sec after when the test with the 1 minute timeout expected which caused the test to fail.
I suggest we bump the timeout a bit since everything seems to be working, it's just taking a bit longer than the timeout is currently set to. This also may be affected by recent which slightly increases how long it takes for pod to be marked as terminal by kubelet.
Change:
s.mux.HandleFunc(s.watchPrefix()+"/", s.handleWatch) <del> s.mux.HandleFunc("/", s.notFound) </del> s.mux.HandleFunc("/proxy/minion/", s.handleMinionReq) return s

Discussion:
sig-release master-blocking build-masterci-kubernetes-build.Overall 2022-06-01 20:49 CEST, commit No response /sig release cc
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
I'm checking that
/assign
this pr should fix
it looks like it's still failing: https://k8s-
/reopen reopening as this is causing all our CI to run against stale artifacts at: v1.25.0-alpha.0.734+
Reopened this issue. <detailsIn response to : /reopen v1.25.0-alpha.0.734+ </details
my previous fix only fixed one side of the things, missing now job are green ! closing for now /close
Closing this issue. <detailsIn response to : my previous fix only fixed one side of the things, missing now job are green /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
thank you !
Change:
select { case <-time.After(timeout): case <-op.notify: <ins> // Re-send on this channel in case there are others // waiting for notification. op.notify <- true </ins> } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When trying to mount an Azure File mount it fails, it looks as though its putting a new line between the name of the Azure Storage Account and the Azure storage domain. There are no new line characters in the secret that holds the account name. The following is the secret: The following is the declaration within the section of the Kubernetes yaml: The following is the error that's shown in `kubectl describe po/pod_name: 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: azure OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): 4.13.0-1011-azure Install tools: Others:
/sig storage
/sig azure
It seems to me that does decode to , so it seems to be behaving correctly. Maybe it's a good idea to trim the return char for and fields after ?
is specified by user, so trim the is not a good idea in the code. Another simple way is to use kubectl create secret to create azure-secret, the accountname and key won't require base64 encoded, so you won't mess up with let me know if you have any question, thanks.
Thanks !
Bumped into this issue today too on our cluster. Can confirm command worked. Is there an easy way to time the /n off the end of the echo for before using base64? Thanks.
yes it's
Of course it is! Doh!
i think would've made better sense to trim the azurestorageaccountname value when receiving it... anyways the storage account name wont have n in them right? I think that just made better developer experience...
is not allowed in azure storage account name
so if azure storage account name does not allow in the name.. then why not just trim the name instead of error... Because devs would just and that would already have the n in the resulting base64-encoded string... right?
sounds reasonable /reopen
Reopened this issue.

<detailsIn response to : sounds reasonable /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
awesome. Thanks
so then this goes in to kube version 1.14.6 in AKS ? or how does this work?
It would only go into k8s v1.16.0 since it's not a critical bug, we don't want to do hot fix to the old release.
got it. thanks Andy.
Change:
path string } <ins> func (v *VersionFile) nextPath() string { return fmt.Sprintf("%s-next", v.path) } </ins> // Exists returns true if a version.txt file exists on the file system. func (v *VersionFile) Exists() (bool, error) { return exists(v.path)

Discussion:
file was found 'empty'. It blocked running etcd in a fail loop with Before this issue: Data disk (etcd) run out of space due to . .txt be not corrupted. It should be updated: only when needed (infrequently) safely (rename swap or writing on pre-allocated space) migrator script that runs etcd in case of the file not being found. Use whole space of etcd data disk and restart migrator+etcd when concurrent process is disk hungry. Requires changes of this logic: This logic (file write) should not trigger if the minor version matches: The write itself: should be defensive: Please notice that truncates file before writingKubernetes version: 1.18 Cloud provider or hardware configuration: GCE
/sig api-machinery
/assign /triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
Change:
} Expect(*(ss.Spec.Replicas)).To(Equal(int32(2))) }) <del> */ </del> }) framework.KubeDescribe("Deploy clustered applications [Feature:StatefulSet] [Slow]", func() {

Discussion:
What would you like to be : e2e test suites for: GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale Why is this needed: PR has already been merged, but the following tests are still commented out. Therefore, scale sub-resource of statefulsets is not tested and test should be . /sig testing
Change:
"//test/integration:all-srcs", "//test/kubemark:all-srcs", "//test/list:all-srcs", <del> "//test/soak/cauldron:all-srcs", </del> "//test/soak/serve_hostnames:all-srcs", "//test/typecheck:all-srcs", "//test/utils:all-srcs",

Discussion:
We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) Apparently the repo is referenced for docker push and pull in It's unclear to me whether we have broken anything, or if this is dead code. I would use to find out if this is referenced anywhere (aside from sundry vendor dirs) If dead code: remove it If used: move to test/e2e/images and follow the same pattern there used to push to /sig testing /area test /wg k8s-infra /priority important-soon /help /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) /area test /wg k8s-infra /priority important-soon /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it 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:
return nil, nil } <ins> func serviceOwnsPublicIP(pip *network.PublicIPAddress, clusterName, serviceName string) bool { if pip != nil && pip.Tags != nil { serviceTag := pip.Tags[serviceTagKey] clusterTag := pip.Tags[clusterNameKey] if serviceTag != nil && *serviceTag == serviceName { // Backward compatible for clusters upgraded from old releases. // In such case, only "service" tag is set. if clusterTag == nil { return true } // If cluster name tag is set, then return true if it matches. if *clusterTag == clusterName { return true } } } return false } </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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
imagePullPolicy: Never args: [ "--etcd-servers=http://localhost:2379" ] - name: etcd <del> image: gcr.io/etcd-development/etcd:v3.5.3 </del> <ins> image: gcr.io/etcd-development/etcd:v3.5.4 </ins>

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
claimAllocations []*controller.ClaimAllocation, selectedNode string), ) { <del> // pod1 will have only external-claim[2-3], it has to wait // for pod2 to consume resources from driver2 if claimAllocations[0].Claim.Name != "external-claim-other" { </del> <ins> if claimAllocations[0].Claim.Name == pod1claim2.Name { </ins> <-blockClaim.Done() } handler(ctx, claimAllocations, selectedNode) return } <ins> b.create(ctx, parameters1, parameters2, pod1claim1, pod1claim2, pod1) </ins> ginkgo.By("waiting for one claim from driver1 to be allocated") var nodeSelector *v1.NodeSelector gomega.Eventually(ctx, func(ctx context.Context) (int, error) {

Discussion:
What happened: Shortly after was merged, the "multiple nodes reallocation works" E2E DRA test started to fail randomly. Please provide links to example occurrences, if any: /sig node /kind bug needs to stay green. No response master n/a No response No response No response No response
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
Change:
apiequality "k8s.io/apimachinery/pkg/api/equality" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/cli-runtime/pkg/genericclioptions" restclient "k8s.io/client-go/rest" "k8s.io/client-go/rest/fake" <ins> "k8s.io/client-go/tools/remotecommand" "k8s.io/kubectl/pkg/cmd/attach" </ins> "k8s.io/kubectl/pkg/cmd/delete" cmdtesting "k8s.io/kubectl/pkg/cmd/testing" cmdutil "k8s.io/kubectl/pkg/cmd/util"

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/reopen
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
/triage accepted
Change:
} pod := podInfo.Pod <del> fwk.EventRecorder().Eventf(pod, nil, v1.EventTypeWarning, "FailedScheduling", "Scheduling", err.Error()) </del> <ins> msg := truncateMessage(err.Error()) fwk.EventRecorder().Eventf(pod, nil, v1.EventTypeWarning, "FailedScheduling", "Scheduling", msg) </ins> if err := updatePod(sched.client, pod, &v1.PodCondition{ Type:    v1.PodScheduled, Status:  v1.ConditionFalse,

Discussion:
What happened: When a pod can't be scheduled and the cardinality of taints on nodes is high, the Note field in the event can become bigger than the 1024 allowed and the event isn't sent. The pod stays in a state of without en event which makes the User Experience very bad What you expected to happen: I would expect the Kube-scheduler to be able to send the event no matter how many different taints are on nodes How to reproduce it (as minimally and precisely as possible): add many different taints to nodes and then trying to schedule something which can't be successfully scheduled (higher CPU/memory than any node has) Anything else we need to know?: In this case the length of the message was 1334 characters. Environment: Kubernetes version (use ): 1.18.9 Cloud provider or hardware configuration: bare metal Possible solutions: make event size configurable, it's now hardcoded to 1024 characters make scheduler note aware of that limit and work around I, if length 1024 then truncate the string (so at least something is shown) produce N events splitting the text (preferred one): change event Note to be to something like: (the whole complete information would still be present in the pod status field. for debugging purposes)
/sig scheduling
/triage accepted /cc
I could provide the fix in case we define which solution is best
This is a consequence of I think we can just drop some reasons when we are building the status message if the message is too large. This comes from here /help
/remove-help /assign
how many different taints did you have? I think in all cases we should truncate the message as well:
Another remidiation is to supress outoutping nil fields (such as GenerateName:"", SelfLink:"", UID:"", ResourceVersion:"", etc.) in the EventRecorder side.
The size limit we're hitting is specifically on the field
Completely agreed
good issue~
/assign
/unassign
Change:
cmdutil.AddDryRunFlag(cmd) cmd.Flags().StringVar(&o.ClusterRole, "clusterrole", "", i18n.T("ClusterRole this RoleBinding should reference")) cmd.Flags().StringVar(&o.Role, "role", "", i18n.T("Role this RoleBinding should reference")) <del> cmd.Flags().StringArrayVar(&o.Users, "user", o.Users, "Usernames to bind to the role") cmd.Flags().StringArrayVar(&o.Groups, "group", o.Groups, "Groups to bind to the role") cmd.Flags().StringArrayVar(&o.ServiceAccounts, "serviceaccount", o.ServiceAccounts, "Service accounts to bind to the role, in the format <namespace>:<name>") </del> <ins> cmd.Flags().StringArrayVar(&o.Users, "user", o.Users, "Usernames to bind to the role. The flag can be repeated to add multiple users.") cmd.Flags().StringArrayVar(&o.Groups, "group", o.Groups, "Groups to bind to the role. The flag can be repeated to add multiple groups.") cmd.Flags().StringArrayVar(&o.ServiceAccounts, "serviceaccount", o.ServiceAccounts, "Service accounts to bind to the role, in the format <namespace>:<name>. The flag can be repeated to add multiple service accounts.") </ins> cmdutil.AddFieldManagerFlagVar(cmd, &o.FieldManager, "kubectl-create") return cmd }

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:
cinderSource := volume.Cinder pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", CinderDriverName, cinderSource.VolumeID), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{

Discussion:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news.

your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after