jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: for k, v := range s.filterTags { filters = append(filters, newEc2Filter("tag:"+k, v)) } <ins> if len(filters) == 0 { // We can't pass a zero-length Filters to AWS (it's an error) // So if we end up with no filters; just return nil return nil } </ins> return filters }
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: "k8s.io/kubernetes/pkg/volume" ) <del> var errUnsupportedVolumeType = fmt.Errorf("unsupported volume type") </del> // This just exports required functions from kubelet proper, for use by volume // plugins. type volumeHost struct {
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: return vh.kubelet.kubeClient } <ins> // NewWrapperMounter attempts to create a volume mounter // from a volume Spec, pod and volume options. // Returns a new volume Mounter or an error. </ins> func (vh *volumeHost) NewWrapperMounter(volName string, spec volume.Spec, pod *api.Pod, opts volume.VolumeOptions) (volume.Mounter, error) { // The name of wrapper volume is set to "wrapped_{wrapped_volume_name}" wrapperVolumeName := "wrapped_" + volName
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: spec.Volume.Name = wrapperVolumeName } <del> b, err := vh.kubelet.newVolumeMounterFromPlugins(&spec, pod, opts) if err == nil && b == nil { return nil, errUnsupportedVolumeType } return b, nil </del> <ins> return vh.kubelet.newVolumeMounterFromPlugins(&spec, pod, opts) </ins> } <ins> // NewWrapperUnmounter attempts to create a volume unmounter // from a volume name and pod uid. // Returns a new volume Unmounter or an error. </ins> func (vh *volumeHost) NewWrapperUnmounter(volName string, spec volume.Spec, podUID types.UID) (volume.Unmounter, error) { // The name of wrapper volume is set to "wrapped_{wrapped_volume_name}" wrapperVolumeName := "wrapped_" + volName
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: if err != nil { return nil, err } <del> if plugin == nil { // Not found but not an error return nil, nil } c, err := plugin.NewUnmounter(spec.Name(), podUID) if err == nil && c == nil { return nil, errUnsupportedVolumeType } return c, nil </del> <ins> return plugin.NewUnmounter(spec.Name(), podUID) </ins> } func (vh *volumeHost) GetCloudProvider() cloudprovider.Interface {
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: glog.Errorf("Could not create volume mounter for pod %s: %v", pod.UID, err) return nil, err } <del> if mounter == nil { return nil, errUnsupportedVolumeType } </del> // some volumes require attachment before mounter's setup. // The plugin can be nil, but non-nil errors are legitimate errors.
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: glog.Errorf("Could not create volume unmounter for %s: %v", volume.Name, err) continue } <del> if unmounter == nil { glog.Errorf("Could not create volume unmounter for %s: %v", volume.Name, errUnsupportedVolumeType) continue } </del> tuple := cleanerTuple{Unmounter: unmounter} detacher, err := kl.newVolumeDetacherFromPlugins(volume.Kind, volume.Name, podUID)
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: return currentVolumes } <ins> // newVolumeMounterFromPlugins attempts to find a plugin by volume spec, pod // and volume options and then creates a Mounter. // Returns a valid Unmounter or an error. </ins> func (kl *Kubelet) newVolumeMounterFromPlugins(spec *volume.Spec, pod *api.Pod, opts volume.VolumeOptions) (volume.Mounter, error) { plugin, err := kl.volumePluginMgr.FindPluginBySpec(spec) if err != nil { return nil, fmt.Errorf("can't use volume plugins for %s: %v", spec.Name(), err) } <del> if plugin == nil { // Not found but not an error return nil, nil } </del> physicalMounter, err := plugin.NewMounter(spec, pod, opts) if err != nil { <del> return nil, fmt.Errorf("failed to instantiate volume physicalMounter for %s: %v", spec.Name(), err) </del> <ins> return nil, fmt.Errorf("failed to instantiate mounter for volume: %s using plugin: %s with a root cause: %v", spec.Name(), plugin.Name(), err) </ins> } glog.V(10).Infof("Used volume plugin %q to mount %s", plugin.Name(), spec.Name()) return physicalMounter, nil } <ins> // newVolumeAttacherFromPlugins attempts to find a plugin from a volume spec // and then create an Attacher. // Returns: //  - an attacher if one exists //  - an error if no plugin was found for the volume //    or the attacher failed to instantiate //  - nil if there is no appropriate attacher for this volume </ins> func (kl *Kubelet) newVolumeAttacherFromPlugins(spec *volume.Spec, pod *api.Pod, opts volume.VolumeOptions) (volume.Attacher, error) { plugin, err := kl.volumePluginMgr.FindAttachablePluginBySpec(spec) if err != nil {
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: return attacher, nil } <ins> // newVolumeUnmounterFromPlugins attempts to find a plugin by name and then // create an Unmounter. // Returns a valid Unmounter or an error. </ins> func (kl *Kubelet) newVolumeUnmounterFromPlugins(kind string, name string, podUID types.UID) (volume.Unmounter, error) { plugName := strings.UnescapeQualifiedNameForDisk(kind) plugin, err := kl.volumePluginMgr.FindPluginByName(plugName)
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: // TODO: Maybe we should launch a cleanup of this dir? return nil, fmt.Errorf("can't use volume plugins for %s/%s: %v", podUID, kind, err) } <del> if plugin == nil { // Not found but not an error. return nil, nil } </del> unmounter, err := plugin.NewUnmounter(name, podUID) if err != nil { return nil, fmt.Errorf("failed to instantiate volume plugin for %s/%s: %v", podUID, kind, err)
Code change:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

Related discussion:
text: return unmounter, nil } <ins> // newVolumeDetacherFromPlugins attempts to find a plugin by a name and then // create a Detacher. // Returns: //  - a detacher if one exists //  - an error if no plugin was found for the volume //    or the detacher failed to instantiate //  - nil if there is no appropriate detacher for this volume </ins> func (kl *Kubelet) newVolumeDetacherFromPlugins(kind string, name string, podUID types.UID) (volume.Detacher, error) { plugName := strings.UnescapeQualifiedNameForDisk(kind) plugin, err := kl.volumePluginMgr.FindAttachablePluginByName(plugName)
Code change:
GCE PD docs so unused blocks can be freed back into the cloud and performance gains realized. Rummaging through the source of the GCE PD and mounter stuff in Kube, it does not appear that that's being done (the old shell script version of safeformatand_mount does, but I don't think that's used). I haven't confirmed that it's the case at runtime for sure, though, although I will be able to shortly.
I LGTMed the PR and then realized it needed more work. Reverting it and assigning it to ciwang. We need to make sure that we only use the "discard" mount option when the fs supports it. Assigning to ciwang for now. If anyone else wants to work on it feel free to grab it.
Assigning to This fell through the cracks as ciwang was working in other areas. This did not make 1.4 either moving to next-candidate.
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close

Related discussion:
text: options := []string{} if readOnly { options = append(options, "ro") <ins> } else { // as per https://cloud.google.com/compute/docs/disks/add-persistent-disk#formatting options = append(options, "discard") </ins> } if notMnt { diskMounter := &mount.SafeFormatAndMount{Interface: mounter, Runner: exec.New()}
Code change:
There was a naive attempt to do this in , but _output it hardcoded throughout the code base so we need a more comprehensive solution.
Do we still need this ?
/sig release
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close

Related discussion:
text: .vscode # This is where the result of the go build goes <del> /output/** /output /_output/** /_output </del> <ins> /output*/ /_output*/ </ins> # Emacs save files *~
Code change:
The e2e test is flaky. It often fails with the error in the test suite. Sample failures: Marking it P0 since it frequently blocks the merge queue.
cc
In the flaky test, the pod is deleted with grace-period=30, but there is no guarantee that the pod is going to be deleted from etcd in 30s, thus the flake. This piece of test is copied from the pod e2e test: In that test, the total timeout is actually larger than 30s, because there is some extra logic (< 30s) between the time when the deletion is requested, and when the timer is started. Given that there is no flake reported for test in , I will fix this flake by extending the timeout to 60s.
This flake should have the same root cause as .
ETA on fix? This is the most frequent cause of test flakes and submit queue blockage.
sent out as a temporary fix.
Hmm, happened in: Which looks like we're just not handling the watch cancellation properly in the test.
does the timeout really fix the watch cancellation? (didn't look too deep at the pr)
I think so. see bprashanth's last comment, the timeout occurs again.
As of 3:20pm Apr.8, last failure occurs at 3:13:18pm, Apr. 7, Mike's fix is merged at 15:04:42, Apr. 7.

Related discussion:
text: deleted := false timeout := false var lastPod *api.Pod <del> timer := time.After(30 * time.Second) </del> <ins> // The 30s grace period is not an upper-bound of the time it takes to // delete the pod from etcd. timer := time.After(60 * time.Second) </ins> for !deleted && !timeout { select { case event, _ := <-w.ResultChan():
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: command := args[0] baseCommand := path.Base(command) serverName := baseCommand <ins> args = args[1:] </ins> if serverName == hk.Name { <del> args = args[1:] </del> baseFlags := hk.Flags() baseFlags.SetInterspersed(false) // Only parse flags up to the next real command
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: "strings" "testing" <ins> "github.com/spf13/cobra" </ins> "github.com/stretchr/testify/assert" )
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: } } <ins> const defaultCobraMessage = "default message from cobra command" const defaultCobraSubMessage = "default sub-message from cobra command" const cobraMessageDesc = "message to print" const cobraSubMessageDesc = "sub-message to print" func testCobraCommand(n string) *Server { var cobraServer *Server var msg string cmd := &cobra.Command{ Use:   n, Long:  n, Short: n, Run: func(cmd *cobra.Command, args []string) { cobraServer.hk.Printf("msg: %sn", msg) }, } cmd.PersistentFlags().StringVar(&msg, "msg", defaultCobraMessage, cobraMessageDesc) var subMsg string subCmdName := "subcommand" subCmd := &cobra.Command{ Use:   subCmdName, Long:  subCmdName, Short: subCmdName, Run: func(cmd *cobra.Command, args []string) { cobraServer.hk.Printf("submsg: %s", subMsg) }, } subCmd.PersistentFlags().StringVar(&subMsg, "submsg", defaultCobraSubMessage, cobraSubMessageDesc) cmd.AddCommand(subCmd) localFlags := cmd.LocalFlags() localFlags.SetInterspersed(false) s := &Server{ SimpleUsage: n, Long:        fmt.Sprintf("A server named %s which uses a cobra command", n), Run: func(s *Server, args []string) error { cobraServer = s cmd.SetOutput(s.hk.Out()) cmd.SetArgs(args) return cmd.Execute() }, flags: localFlags, } return s } </ins> func runFull(t *testing.T, args string) *result { buf := new(bytes.Buffer) hk := HyperKube{
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: hk.AddServer(testServer("test2")) hk.AddServer(testServer("test3")) hk.AddServer(testServerError("test-error")) <ins> hk.AddServer(testCobraCommand("test-cobra-command")) </ins> a := strings.Split(args, " ") t.Logf("Running full with args: %q", a)
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: assert.Contains(t, x.output, "test-error Run") assert.EqualError(t, x.err, "Server returning error") } <ins> func TestCobraCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --help") assert.NoError(t, x.err) assert.Contains(t, x.output, "A server named test-cobra-command which uses a cobra command") assert.Contains(t, x.output, cobraMessageDesc) } func TestCobraCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command") assert.Contains(t, x.output, fmt.Sprintf("msg: %s", defaultCobraMessage)) } func TestCobraCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --msg foobar") assert.Contains(t, x.output, "msg: foobar") } func TestCobraSubCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --help") assert.NoError(t, x.err) assert.Contains(t, x.output, cobraSubMessageDesc) } func TestCobraSubCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand") assert.Contains(t, x.output, fmt.Sprintf("submsg: %s", defaultCobraSubMessage)) } func TestCobraSubCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --submsg foobar") assert.Contains(t, x.output, "submsg: foobar") } </ins>
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: import ( "os" <del> "k8s.io/kubernetes/cmd/kubectl/app" </del> <ins> "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" </ins> ) func NewKubectlServer() *Server { <ins> cmd := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, os.Stdout, os.Stderr) localFlags := cmd.LocalFlags() localFlags.SetInterspersed(false) </ins> return &Server{ name:        "kubectl", SimpleUsage: "Kubernetes command line client", Long:        "Kubernetes command line client", Run: func(s *Server, args []string) error { <del> os.Args = os.Args[1:] if err := app.Run(); err != nil { os.Exit(1) } os.Exit(0) return nil </del> <ins> cmd.SetArgs(args) return cmd.Execute() </ins> }, <ins> flags: localFlags, </ins> } }
Code change:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .

Related discussion:
text: cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" ) <ins> /* WARNING: this logic is duplicated, with minor changes, in cmd/hyperkube/kubectl.go Any salient changes here will need to be manually reflected in that file. */ </ins> func Run() error { cmd := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, os.Stdout, os.Stderr) return cmd.Execute()