jiebi/CodeConvo huggingface dataset:
Code change:
serviceAccountName: csi-mock containers: - name: csi-provisioner <del> image: registry.k8s.io/sig-storage/csi-provisioner:v3.3.0 </del> <ins> image: registry.k8s.io/sig-storage/csi-provisioner:v3.4.0 </ins> args: - "--csi-address=$(ADDRESS)" # Topology support is needed for the pod rescheduling test

Related discussion:
text: Seen in pull-kubernetes-e2e-gce-cos-alpha-features Specific job failure
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
from the error message I don't know if it refers to the sig-storage error or to the sig-auth one
/sig storage
/kind failing-test
/assign From : ... I am not sure if it's related:
is the culprit. cannot be used inside a . This only gets caught when the test actually runs, otherwise Ginkgo never sees the incorrect .
I don’t understand why sometimes it can get the pv by namebut sometimes it failed
but then is a sig-auth test , not storage , sorry /sig auth this seems that was recently in
/remove sig-storage
/assign /priority important-soon
/unassign
is still failed. seems not fixing the whole problem. /reopen feel free to close if the ci is green.
Reopened this issue. <detailsIn response to : is still failed. /reopen feel free to close if the ci is green. 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 failure now looks like it is just a sig storage issue:
cc
/assign looks like the new test is still an issue
I think this line is the problem: When the test creates the object, it may take time for the PV to be provisioned and to be bound to the PVC. So you should do another before this call so you can get the latest PVC object with the bound PV.
I opened to get PVC again before using .
Only do PersistentVolumeClaims.Get() is not enough, whether we need to wait for sometimes to wait it bound? because sometimes the testcase is successful and sometime is failed.
If the Pod was able to run, then the PVC has to be bound.
so I can't understand why sometimes the testcase is successful and sometimes is failed.
Code change:
serviceAccountName: csi-mock containers: - name: csi-provisioner <del> image: registry.k8s.io/sig-storage/csi-provisioner:v3.3.0 </del> <ins> image: registry.k8s.io/sig-storage/csi-provisioner:v3.4.0 </ins> args: - "--csi-address=$(ADDRESS)" # Topology support is needed for the pod rescheduling test

Related discussion:
text: By default, the DelayBinding is false, it will wait for PVC bound during creation. This is weird.
It waits for the claim to be bound, but the test case still needs to refresh its pvc object.
Because of the refresh is async, so after the pvc was bound, we need to get the pvc again, isn't it?
Code change:
w.Flush() if trackingWriter.Written == 0 && !o.IgnoreNotFound && len(allErrs) == 0 { // if we wrote no output, and had no errors, and are not ignoring NotFound, be sure we output something <del> fmt.Fprintln(o.ErrOut, "No resources found.") </del> <ins> noResourcesFoundFormat := fmt.Sprintf("No resources found in %s namespace.", o.Namespace) fmt.Fprintln(o.ErrOut, noResourcesFoundFormat) </ins> } return utilerrors.NewAggregate(allErrs) }

Related discussion:
text: So I started using namespaces for the first time, and I ran: nothing was showing up...I was really confused, debugging stuff for 30+ minutes.. finally I was like, even tho this is really dumb, maybe they are behind a namespace, so I did: and finally my pods showed up. so yes there is: but this should really be the default, shouldn't it? You will save people a lot of time if you make this fix. tbh, this is a really crappy cli design in this case.
While this might sound like a good idea if you're running a single deployment with a few pods, once you start running multiple dozens of deployments and objects it starts to become less and less useful to have this become the default. I also suspect exposing all objects without specifying namespace is probably a non-goal. Namespaces were created for a reason which is to logically segment resources together. In my opinion, what you are suggesting just nullifies the entire purpose of namespaces.
I think this is more of a usability bug. kubectl get pods gives the list of all pods in default namespace.By default no pods are present in default namespace. So it does give a message saying No Resources found. Improving this message a little bit will be helpful like No Resources found in default namespace
/sig cli
I could implement this if that's alright with you !
sure, how about
We should wait for kubernetes members to comment if this change should be taken up
The title of this issue could use an update, if the priority has been shifted to improving the output of an empty namespace. Maybe it's early to claim the consensus seems to be that --all-namespaces should not be the default, but I personally agree that it shouldn't be. Take note of the shorthand , to make typing it a bit easier, or the option to to something other than to get around typing your namespace altogether.
:) IMHO, is innocent. But we could make the messages more clear. For example, will show also. And is a bit long, but a is too simple to describe our intent, "all namespaces of cluster or all some resource of some namespace", so puzzled. My conclusion: is competent, namespace is ok, making more clear message is enough.
"~" is already implemented as in , in .
Code change:
w.Flush() if trackingWriter.Written == 0 && !o.IgnoreNotFound && len(allErrs) == 0 { // if we wrote no output, and had no errors, and are not ignoring NotFound, be sure we output something <del> fmt.Fprintln(o.ErrOut, "No resources found.") </del> <ins> noResourcesFoundFormat := fmt.Sprintf("No resources found in %s namespace.", o.Namespace) fmt.Fprintln(o.ErrOut, noResourcesFoundFormat) </ins> } return utilerrors.NewAggregate(allErrs) }

Related discussion:
text: Not sure if I came across as suggesting a new shorthand or if I misread your comment, but for clarity's sake there it is.
the problem is that the nixos-rebuild command is not available on non-NixOS linux machines. However, the underlying issue is that if we run we get this error:
Code change:
import ( "fmt" <ins> "io/ioutil" </ins> "os" "runtime"

Related discussion:
text: <!-- 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?: /kind bug What happened: azure file plugin on Windows does not work after node restart, this is due to powershell cmdlet has lost account name/key after reboot, we should remove the invalid link and do the mount again after kubelet restart. What you expected to happen: azure file plugin on Windows should work after node restart How to reproduce it (as minimally and precisely as possible): has created a pod with azure file mount on Windows agent node could get following error: Anything else we need to know?: Environment: Kubernetes version (use ): v1.9, v1.10 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign /sig windows /sig azure
Added to v1.10 milestone since it is a critical bug fix. cc
Code change:
return volumesToReportAttached } <ins> func (asw *actualStateOfWorld) GetNodesToUpdateStatusFor() map[types.NodeName]nodeToUpdateStatusFor { return asw.nodesToUpdateStatusFor } </ins> func getAttachedVolume( attachedVolume *attachedVolume, nodeAttachedTo *nodeAttachedTo) AttachedVolume {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: $ kubectl describe pods test-ipj93 Name: test-ipj93 Namespace: default Node: kubernetes-minion-group-yxra/10.128.0.3 Start Time: Mon, 28 Nov 2016 14:39:28 -0800 Labels: <noneStatus: Pending IP: Controllers: <noneContainers: busybox: Container ID: Image: busybox Image ID: Port: Command: sh -c while true; do echo (hostname)-(cat /proc/stat cut -f 4 -d" "); sleep 30; done QoS Tier: cpu: Burstable memory: BestEffort Requests: cpu: 100m State: Waiting Reason: ContainerCreating Ready: False Restart Count: 0 Environment Variables: Conditions: Type Status Initialized True Ready False PodScheduled True Volumes: data: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: test ReadOnly: false default-token-kjoqg: Type: Secret (a volume populated by a Secret) SecretName: default-token-kjoqg Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 57m 57m 1 {default-scheduler } Normal Scheduled Successfully assigned test-ipj93 to kubernetes-minion-group-yxra 57m 57m 1 {kubelet kubernetes-minion-group-yxra} spec.containers{busybox} Normal Pulling pulling image "busybox" 57m 57m 1 {kubelet kubernetes-minion-group-yxra} spec.containers{busybox} Normal Pulled Successfully pulled image "busybox" 57m 57m 1 {kubelet kubernetes-minion-group-yxra} spec.containers{busybox} Normal Created Created container with docker id ; Security:[seccomp=unconfined] 57m 57m 1 {kubelet kubernetes-minion-group-yxra} spec.containers{busybox} Normal Started Started container with docker id 47m 47m 6 {kubelet kubernetes-minion-group-yxra} Warning FailedMount MountVolume.
Code change:
return volumesToReportAttached } <ins> func (asw *actualStateOfWorld) GetNodesToUpdateStatusFor() map[types.NodeName]nodeToUpdateStatusFor { return asw.nodesToUpdateStatusFor } </ins> func getAttachedVolume( attachedVolume *attachedVolume, nodeAttachedTo *nodeAttachedTo) AttachedVolume {

Related discussion:
text: SetUp failed for volume "" (spec.Name: "default-token-kjoqg") pod "-b5bb-11e6-bab0-" (UID: "-b5bb-11e6-bab0-") with: Get https://kubernetes-master/api/v1/namespaces/default/secrets/default-token-kjoqg: dial tcp: lookup kubernetes-master on 169.254.169.254:53: no such host 46m 46m 1 {kubelet kubernetes-minion-group-yxra} Warning FailedMount MountVolume.SetUp failed for volume "" (spec.Name: "default-token-kjoqg") pod "-b5bb-11e6-bab0-" (UID: "-b5bb-11e6-bab0-") with: Get https://kubernetes-master/api/v1/namespaces/default/secrets/default-token-kjoqg: dial tcp 10.128.0.2:443: i/o timeout 45m 45m 1 {kubelet kubernetes-minion-group-yxra} Warning FailedMount MountVolume.SetUp failed for volume "" (spec.Name: "default-token-kjoqg") pod "-b5bb-11e6-bab0-" (UID: "-b5bb-11e6-bab0-") with: Get https://kubernetes-master/api/v1/namespaces/default/secrets/default-token-kjoqg: dial tcp 10.128.0.2:443: getsockopt: connection refused 11m 11m 2 {controller-manager } Warning FailedMount Failed to attach volume "test" on node "kubernetes-minion-group-yxra" with: error getting instance "kubernetes-minion-group-yxra" 9m 9m 1 {kubelet kubernetes-minion-group-yxra} Warning FailedSync Error syncing pod, skipping: network is not ready: [Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] 9m 9m 2 {kubelet kubernetes-minion-group-yxra} Warning FailedSync Error syncing pod, skipping: network is not ready: [Kubenet does not have netConfig.
Code change:
return volumesToReportAttached } <ins> func (asw *actualStateOfWorld) GetNodesToUpdateStatusFor() map[types.NodeName]nodeToUpdateStatusFor { return asw.nodesToUpdateStatusFor } </ins> func getAttachedVolume( attachedVolume *attachedVolume, nodeAttachedTo *nodeAttachedTo) AttachedVolume {

Related discussion:
text: This is most likely due to lack of PodCIDR] 6m 14s 4 {kubelet kubernetes-minion-group-yxra} Warning FailedMount Unable to mount volumes for pod "test-ipj93_default(-b5bb-11e6-bab0-)": timeout expired waiting for volumes to attach/mount for pod "test-ipj93"/"default". list of unattached/unmounted volumes=[data] 6m 14s 4 {kubelet kubernetes-minion-group-yxra} Warning FailedSync Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "test-ipj93"/"default". list of unattached/unmounted volumes=[data] What you expected to happen: GCE PD to attach and mount successfully post the upgrade How to reproduce it (as minimally and precisely as possible): Running the upgrade steps in the doc for upgrade of manual test from 1.4 to 1.5 Anything else do we need to know:
Ran the upgrade again. This time the .
kube-controller-
Current theory is because kubelet deletes and recreates the node API object during upgrade (because externalID changed), see the new object does not contain the correct status (it is written by the Attach/Detach controller to the old object but not subseqently updated). If this proves to be the issue, the proposed fix is to force the attach/detach controller to update the node status when the node's external ID changes. is working to verify this theory by executing this code path (without a full upgrade). Once he has validated the theory, he will work on the fix, verify it, merge it to master, and get it cherry-picked to 1.5.
: is expected to fix this problem?
: Yes
Code change:
} } <ins> func proxyRedirectsforRootPath(path string, w http.ResponseWriter, req *http.Request) bool { redirect := false method := req.Method // From pkg/genericapiserver/endpoints/handlers/proxy.go#ServeHTTP: // Redirect requests with an empty path to a location that ends with a '/' // This is essentially a hack for http://issue.k8s.io/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(path) == 0 && (method == http.MethodGet || method == http.MethodHead) { var queryPart string if len(req.URL.RawQuery) > 0 { queryPart = "?" + req.URL.RawQuery } w.Header().Set("Location", req.URL.Path+"/"+queryPart) w.WriteHeader(http.StatusMovedPermanently) redirect = true } return redirect } </ins> // ServeHTTP handles the proxy request func (h *UpgradeAwareHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) { if h.tryUpgrade(w, req) {

Related discussion:
text: What happened: As part of creating an e2e test for , it was found that the apiserver proxy server is processing a blank redirect for any for 21 endpoints across pods, services and nodes. For a pod, redirecting for any method other than GET or HEAD is a bug, you expected to happen: This is the current behaviour for the apiserver but with a minimal code change the redirect can apply to only the following endpoints; - - - How to reproduce it (as minimally and precisely as possible): Create any standard pod and service in the default namespace run in another terminal the response from running the following commands produces a can be replaced with other http verbs , , , , and which also produce 301 responses. Anything else we need to know?: networking /sig testing /sig architecture
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: - - - run in another terminal the response from running the following commands produces a testing /sig architecture 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
Does this issue and PR address your concerns about the apiserver proxy server doing a blanket direct of any http call to the root proxy endpoints?
commented on the associated PR, thanks
/remove-sig testing
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
/remove-lifecycle stale Will be addressed late in 1.21
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
} } <ins> func proxyRedirectsforRootPath(path string, w http.ResponseWriter, req *http.Request) bool { redirect := false method := req.Method // From pkg/genericapiserver/endpoints/handlers/proxy.go#ServeHTTP: // Redirect requests with an empty path to a location that ends with a '/' // This is essentially a hack for http://issue.k8s.io/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(path) == 0 && (method == http.MethodGet || method == http.MethodHead) { var queryPart string if len(req.URL.RawQuery) > 0 { queryPart = "?" + req.URL.RawQuery } w.Header().Set("Location", req.URL.Path+"/"+queryPart) w.WriteHeader(http.StatusMovedPermanently) redirect = true } return redirect } </ins> // ServeHTTP handles the proxy request func (h *UpgradeAwareHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) { if h.tryUpgrade(w, req) {

Related discussion:
text: This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle stale
/remove-lifecycle stale
Code change:
By("Removing the test directory") removeCmd := fmt.Sprintf("rm -r %s", path.Join(hostBase, discoveryDir)) <del> _, err := framework.NodeExec(config.node0.Name, removeCmd) </del> <ins> err := framework.IssueSSHCommand(removeCmd, framework.TestContext.Provider, config.node0) </ins> Expect(err).NotTo(HaveOccurred()) By("Cleaning up persistent volume")

Related discussion:
text: 8 tests failed, 2 jobs failed, 88 builds failed. Failure stats cover 1 day time range '3 Aug 2017 03:31 UTC' to '4 Aug 2017 03:31 UTC'.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage
This should have been fixed by /cc
The test panic is fixed, but now it's failing because it can't SSH into the node.
/assign
Code change:
Limiter flowcontrol.RateLimiter }{ { <ins> Name:    "with no QPS", </ins> Config:  Config{}, Limiter: flowcontrol.NewTokenBucketRateLimiter(5, 10), }, { <ins> Name:    "with QPS:10", </ins> Config:  Config{QPS: 10}, Limiter: flowcontrol.NewTokenBucketRateLimiter(10, 10), }, { <ins> Name:    "with QPS:-1", </ins> Config:  Config{QPS: -1}, Limiter: nil, }, { <ins> Name: "with RateLimiter", </ins> Config: Config{ RateLimiter: flowcontrol.NewTokenBucketRateLimiter(11, 12), },

Related discussion:
text: Reading TestRESTClientLimiter in I noticed a few things. test case struct is defined to have a name field, and its value is used in naming the subtests, but the actual test cases leave the name blank. error statements do not identify which case is failing (do not identify the expected value). Should be clear from the above. Read the code. No response_ <detailsbranch </details<detailsN/A </details<detailsN/A </details<details</details<details</details<details</details
/sig api-machinery
/assign
/triage accepted
Code change:
if svcInfo.preserveDIP || svcInfo.localTrafficDSR { lbIngressEndpoints = hnsLocalEndpoints } <del> hnsLoadBalancer, err := hns.getLoadBalancer( lbIngressEndpoints, loadBalancerFlags{isDSR: svcInfo.preserveDIP || svcInfo.localTrafficDSR, useMUX: svcInfo.preserveDIP, preserveDIP: svcInfo.preserveDIP, sessionAffinity: sessionAffinityClientIP, isIPv6: proxier.isIPv6Mode}, sourceVip, lbIngressIP.ip, Enum(svcInfo.Protocol()), uint16(svcInfo.targetPort), uint16(svcInfo.Port()), ) if err != nil { klog.ErrorS(err, "Policy creation failed") continue </del> <ins> if len(lbIngressEndpoints) > 0 { hnsLoadBalancer, err := hns.getLoadBalancer( lbIngressEndpoints, loadBalancerFlags{isDSR: svcInfo.preserveDIP || svcInfo.localTrafficDSR, useMUX: svcInfo.preserveDIP, preserveDIP: svcInfo.preserveDIP, sessionAffinity: sessionAffinityClientIP, isIPv6: proxier.isIPv6Mode}, sourceVip, lbIngressIP.ip, Enum(svcInfo.Protocol()), uint16(svcInfo.targetPort), uint16(svcInfo.Port()), ) if err != nil { klog.ErrorS(err, "Policy creation failed") continue } lbIngressIP.hnsID = hnsLoadBalancer.hnsID klog.V(3).InfoS("Hns LoadBalancer resource created for loadBalancer Ingress resources", "lbIngressIP", lbIngressIP) } else { klog.V(3).InfoS("Skipped creating Hns LoadBalancer for loadBalancer Ingress resources", "lbIngressIP", lbIngressIP) </ins> } <del> lbIngressIP.hnsID = hnsLoadBalancer.hnsID klog.V(3).InfoS("Hns LoadBalancer resource created for loadBalancer Ingress resources", "lbIngressIP", lbIngressIP) </del> } svcInfo.policyApplied = true klog.V(2).InfoS("Policy successfully applied for service", "serviceInfo", svcInfo)

Related discussion:
text: During a Kubernetes deployment the connectivity to web services from Windows nodes is flapping. There are intermittent traffic delays and some errors observed on web services during the deployment. Post deployment the flapping is no longer observed. No flapping in connectivity during the deployment. Create a deployment with multiple services and monitor connectivity. No response <details20 </details<detailsAKS </details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
Code change:
klog.V(3).Infof("No %s PriorityLevelConfiguration found, imagining one", proto.Name) labelValues := []string{proto.Name} reqsObsPair := meal.cfgCtlr.reqsObsPairGenerator.Generate(1, 1, labelValues) <del> execSeatsObs := meal.cfgCtlr.execSeatsObsGenerator.Generate(1, 1, labelValues) </del> <ins> execSeatsObs := meal.cfgCtlr.execSeatsObsGenerator.Generate(0, 1, labelValues) </ins> qsCompleter, err := queueSetCompleterForPL(meal.cfgCtlr.queueSetFactory, nil, proto, requestWaitLimit, reqsObsPair, execSeatsObs) if err != nil { // This can not happen because proto is one of the mandatory

Related discussion:
text: While investigating another issue, I noticed that the histograms never get an Observation of zero. This makes no sense. See and related following remarks for some details. I expected the count of seats occupied by executing requests to be zero some times. Start an apiserver and scrape it; look at and see that the value is zero. No response <details</details<detailsnone </details<details</details<details</details<details</details<details</details