jiebi/CodeConvo huggingface dataset:
Change:
/kind bug What happened: Pod stays in terminating status forever What you expected to happen: POD removed. How to reproduce it (as minimally and precisely as possible): Provision container with PVC (Dynamic provisioned) using GlusterFS wait untill running and then remove POD Anything else we need to know?: Events: kubelet log Environment: Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-10T15:38:08Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} hardware cat /etc/os-release NAME="Container Linux by CoreOS" ID=coreos VERSION=1381.1.0 VERSIONID=1381.1.0 BUILDID=2017-04-25-2232 PRETTYNAME="Container Linux by CoreOS 1381.1.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" COREOSBOARD="amd64-usr" Linux server37 4.10.12-coreos SMP Tue Apr 25 22:08:35 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz GenuineIntel GNU/Linux Install tools: hyperkube
/sig node
+1
+1
This should be fixed by
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
Actually will avoid printing out the error message "Could not construct volume information ..", but I believe that is not the root cause of the issue here.
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
I had the same issue for v1.11. Pod has state Terminating. Container is alive on node in Docker 1.13. Describe shows

Discussion:
} func (plugin *glusterfsPlugin) ConstructVolumeSpec(volumeName, mountPath string) (*volume.Spec, error) { <del> glusterfsVolume := &v1.Volume{ Name: volumeName, VolumeSource: v1.VolumeSource{ Glusterfs: &v1.GlusterfsVolumeSource{ EndpointsName: volumeName, Path:          volumeName, }, }, } return volume.NewSpecFromVolume(glusterfsVolume), nil </del> <ins> // To reconstrcut volume spec we need endpoint where fetching endpoint from mount // string looks to be impossible, so returning error. return nil, fmt.Errorf("impossible to reconstruct glusterfs volume spec from volume mountpath") </ins> } // Glusterfs volumes represent a bare host file or directory mount of an Glusterfs export.
Change:
<!-- 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: BASEIMAGE for resource-consumer was ubuntu before and there is a ask for migrating to debian via - What you expected to happen: Use debian-base as BASEIMAGE for resource-consumer test image How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
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 testing

Discussion:
<del> amd64=gcr.io/google-containers/ubuntu-slim-amd64:0.12 arm=gcr.io/google-containers/ubuntu-slim-arm:0.12 arm64=gcr.io/google-containers/ubuntu-slim-arm64:0.12 ppc64le=gcr.io/google-containers/ubuntu-slim-ppc64le:0.12 </del> <ins> amd64=gcr.io/google-containers/debian-base-amd64:0.1 arm=gcr.io/google-containers/debian-base-arm:0.1 arm64=gcr.io/google-containers/debian-base-arm64:0.1 ppc64le=gcr.io/google-containers/debian-base-ppc64le:0.1 </ins>

CROSS_BUILD_COPY qemu-QEMUARCH-static /usr/bin/ <del> RUN apt-get update && apt-get install -y --no-install-recommends stress &&  rm -rf /var/lib/apt/lists/* </del> <ins> RUN clean-install stress </ins> ADD consumer /consumer ADD consume-cpu /consume-cpu

<del> 1.0 </del> <ins> 1.1 </ins>
Change:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: If you are using a mac and GCE and you specify NODELOCALSSDS=0 when using GCE via kube-up or e2e --up, then you end up getting 2 local SSDs. What you expected to happen: I would expect to get 0 local SSDs by default and when I specify NODELOCALSSDS=0 explicitly. How to reproduce it (as minimally and precisely as possible): On mac execute: NODELOCALSSDS=0 go run -- -v --up Anything else we need to know?: I've discovered that this issue is due to If NODELOCALSSDS=0, this evaluates to $(seq 0) From man seq on mac osx This was run on mac with the seq manpage indicating it comes from BSD Feb 19 2010. Note: some unix/linux variants, e.g. a test on ubuntu with coreutils 8.25 and a test on centos-7 with coreutils 8.22, had a different behavior that does not demonstrate this bug. Environment: Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): mac osx
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

Discussion:
local local_ssds="" if [[ ! -z ${NODE_LOCAL_SSDS+x} ]]; then <ins> # The NODE_LOCAL_SSDS check below fixes issue #49171 # Some versions of seq will count down from 1 if "seq 0" is specified if [[ ${NODE_LOCAL_SSDS} -ge 1 ]]; then </ins> for i in $(seq ${NODE_LOCAL_SSDS}); do <del> local_ssds="$local_ssds--local-ssd=interface=SCSI " </del> <ins> local_ssds="$local_ssds--local-ssd=interface=SCSI " </ins> done <ins> fi </ins> fi local network=$(make-gcloud-network-argument
Change:
We suspect that caused the failures. /sig storage /kind bug
/assign
Fixed by
/assign
GitHub didn't allow me to assign the following users: humblec. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
mkdir -p "${CONTAINERIZED_MOUNTER_HOME}/rootfs" local -r mounter_tar_sha="8003b798cf33c7f91320cd6ee5cec4fa22244571" download-or-bust "${mounter_tar_sha}" "https://storage.googleapis.com/kubernetes-release/gci-mounter/mounter.tar" <del> cp "${KUBE_HOME}/kube-manifests/gci-trusty/gci-mounter" "${CONTAINERIZED_MOUNTER_HOME}/mounter" </del> <ins> cp "${KUBE_HOME}/kube-manifests/kubernetes/gci-trusty/gci-mounter" "${CONTAINERIZED_MOUNTER_HOME}/mounter" </ins> chmod a+x "${CONTAINERIZED_MOUNTER_HOME}/mounter" mv "${KUBE_HOME}/mounter.tar" /tmp/mounter.tar tar xf /tmp/mounter.tar -C "${CONTAINERIZED_MOUNTER_HOME}/rootfs"
Change:
<!-- 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?: FEATURE REQUEST What happened: ! ! What you expected to happen: "kubectl describe pdb" may contain namespaces. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.687+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T02:17:22Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.687+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T02:17:22Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" IDLIKE="rhel fedora" VERSIONID="7" PRETTYNAME="CentOS Linux 7 (Core)" ANSICOLOR="0;31" CPENAME="cpe:/o:centos:centos:7" HOMEURL="" BUGREPORTURL="" CENTOSMANTISBTPROJECT="CentOS-7" CENTOSMANTISBTPROJECTVERSION="7" REDHATSUPPORTPRODUCT="centos" REDHATSUPPORTPRODUCTVERSION="7" Kernel (e.g. ): Linux k8s 3.10.0-514.26.1.el7.x8664 SMP Thu Jun 29 16:05:25 UTC 2017 x8664 x8664 x8664 GNU/LinuxInstall tools: rpm Others:
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 cli
/sig cli
/kind bug

Discussion:
return tabbedString(func(out io.Writer) error { w := NewPrefixWriter(out) w.Write(LEVEL_0, "Name:t%sn", pdb.Name) <ins> w.Write(LEVEL_0, "Namespace:t%sn", pdb.Namespace) </ins> if pdb.Spec.MinAvailable != nil { w.Write(LEVEL_0, "Min available:t%sn", pdb.Spec.MinAvailable.String())
Change:
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 api-machinery

Discussion:
"net/url" "reflect" "strings" <ins> "sync/atomic" </ins> "testing" "golang.org/x/net/websocket"

for k, tc := range testcases { tcName := k path := "/apis/" + tc.APIService.Spec.Group + "/" + tc.APIService.Spec.Version + "/foo" <del> called := false </del> <ins> timesCalled := int32(0) </ins> func() { // Cleanup after each test case. backendHandler := http.NewServeMux() backendHandler.Handle(path, websocket.Handler(func(ws *websocket.Conn) { <ins> atomic.AddInt32(&timesCalled, 1) </ins> defer ws.Close() body := make([]byte, 5) ws.Read(body) ws.Write([]byte("hello " + string(body))) <del> called = true </del> })) backendServer := httptest.NewUnstartedServer(backendHandler)

defer backendServer.Close() defer func() { <del> if called != tc.ExpectCalled { </del> <ins> if called := atomic.LoadInt32(&timesCalled) > 0; called != tc.ExpectCalled { </ins> t.Errorf("%s: expected called=%v, got %v", tcName, tc.ExpectCalled, called) } }()
Change:
Seeing a variety of failures Address already in use failures https://k8s- Stack traces: https://k8s- https://k8s- Creation errors: https://k8s-
cc
Here's another false negative in TestEtcdStoragePath: https://k8s-

Discussion:
genericapiserver "k8s.io/apiserver/pkg/server" "k8s.io/apiserver/pkg/storage/storagebackend" clientset "k8s.io/client-go/kubernetes" <del> kclient "k8s.io/client-go/kubernetes" </del> restclient "k8s.io/client-go/rest" "k8s.io/client-go/tools/clientcmd" clientcmdapi "k8s.io/client-go/tools/clientcmd/api"

storageConfigValue := atomic.Value{} go func() { <ins> // Catch panics that occur in this go routine so we get a comprehensible failure defer func() { if err := recover(); err != nil { t.Errorf("Unexpected panic trying to start API master: %#v", err) } }() </ins> for { kubeAPIServerOptions := options.NewServerRunOptions() kubeAPIServerOptions.SecureServing.BindAddress = net.ParseIP("127.0.0.1")

t.Log(err) } <del> time.Sleep(100 * time.Millisecond) </del> <ins> time.Sleep(time.Second) </ins> } }() <del> if err := wait.PollImmediate(100*time.Millisecond, 10*time.Second, func() (done bool, err error) { </del> <ins> if err := wait.PollImmediate(time.Second, time.Minute, func() (done bool, err error) { </ins> obj := kubeClientConfigValue.Load() if obj == nil { return false, nil } kubeClientConfig := kubeClientConfigValue.Load().(*restclient.Config) <del> kubeClient, err := kclient.NewForConfig(kubeClientConfig) </del> <ins> // make a copy so we can mutate it to set GroupVersion and NegotiatedSerializer cfg := *kubeClientConfig cfg.ContentConfig.GroupVersion = &schema.GroupVersion{} cfg.ContentConfig.NegotiatedSerializer = kapi.Codecs privilegedClient, err := restclient.RESTClientFor(&cfg) </ins> if err != nil { // this happens because we race the API server start t.Log(err) return false, nil } <del> if _, err := kubeClient.Discovery().ServerVersion(); err != nil { </del> <ins> // wait for the server to be healthy result := privilegedClient.Get().AbsPath("/healthz").Do() if errResult := result.Error(); errResult != nil { t.Log(errResult) </ins> return false, nil } <del> return true, nil </del> <ins> var status int result.StatusCode(&status) return status == http.StatusOK, nil </ins> }); err != nil { t.Fatal(err) }
Change:
In volume management code, VolumeSpec is firstly needed to find the volume plugin. After the volume plugin is found, VolumeSpec is again used to attach or mount or check volume is still attached or not. This information is reconstructed during controller failure. The assumptions used here are If pod still exists, VolumeSpec should be reconstructed when controller is restarted. However, as discover from this bug, it might not be true if PVC is deleted in the meantime because pod only has PVC information and requires to use PVC to get PV information. By fixing Issue , we could fix this problem.If pod is already deleted, VolumeSpec is not really needed for detaching. But before detaching finishes, syncState loop might check this volume's attachement status and will use VolumeSpec during checking. One safe guard we can put here is to fail FindAttachablePluginBySpec if spec is nil. This function is used by multiple places such as attachdetachcontroller, desiredstateofworld, and actualstateofworld, oeperation_generator etc. Instead of adding nil check many places, I feel FindAttachablePluginBySpec or even better FindPluginBySpec (is called by FindAttachablePluginBySpec and other places). Open an issue for this
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
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

Discussion:
pm.mutex.Lock() defer pm.mutex.Unlock() <ins> if spec == nil { return nil, fmt.Errorf("Could not find plugin because volume spec is nil") } </ins> matches := []string{} for k, v := range pm.plugins { if v.CanSupport(spec) {

if plug.GetPluginName() != "testPlugin" { t.Errorf("Wrong name: %s", plug.GetPluginName()) } <ins> plug, err = vpm.FindPluginBySpec(nil) if err == nil { t.Errorf("Should return error if volume spec is nil") } volumeSpec := &Spec{} plug, err = vpm.FindPluginBySpec(volumeSpec) if err != nil { t.Errorf("Should return test plugin if volume spec is not nil") } </ins> } func Test_ValidatePodTemplate(t *testing.T) {
Change:
validated in case len(r.PolicyRule.NonResourceURLs) 0 is useless. Just for merge. ref to
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 auth
I think this issue can be closed now. has been merged and solves this.

Discussion:
return PolicyRule{}, fmt.Errorf("non-resource rule may not have apiGroups, resources, or resourceNames: %#v", r.PolicyRule) } case len(r.PolicyRule.Resources) > 0: <del> if len(r.PolicyRule.NonResourceURLs) != 0 { return PolicyRule{}, fmt.Errorf("resource rule may not have nonResourceURLs: %#v", r.PolicyRule) } </del> <ins> // resource rule may not have nonResourceURLs </ins> if len(r.PolicyRule.APIGroups) == 0 { // this a common bug return PolicyRule{}, fmt.Errorf("resource rule must have apiGroups: %#v", r.PolicyRule)
Change:
Currently we don't check if disk is already attached : from what i remember it can cause some problems, but not sure, sorry for the mass tag
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 /assign

Discussion:
glog.Errorf("Photon Controller attacher: Attach failed to get volume source") return "", err } <ins> attached, err := attacher.photonDisks.DiskIsAttached(volumeSource.PdID, nodeName) </ins> <del> glog.V(4).Infof("Photon Controller: Attach disk called for host %s", hostName) // TODO: if disk is already attached? err = attacher.photonDisks.AttachDisk(volumeSource.PdID, nodeName) </del> if err != nil { <del> glog.Errorf("Error attaching volume %q to node %q: %+v", volumeSource.PdID, nodeName, err) return "", err </del> <ins> glog.Warningf("Photon Controller: couldn't check if disk is Attached for host %s, will try attach disk: %+v", hostName, err) attached = false } if !attached { glog.V(4).Infof("Photon Controller: Attach disk called for host %s", hostName) err = attacher.photonDisks.AttachDisk(volumeSource.PdID, nodeName) if err != nil { glog.Errorf("Error attaching volume %q to node %q: %+v", volumeSource.PdID, nodeName, err) return "", err } </ins> } PdidWithNoHypens := strings.Replace(volumeSource.PdID, "-", "", -1)

nodeName := types.NodeName("instance") readOnly := false spec := createVolSpec(diskName, readOnly) <del> attachError := errors.New("Fake attach error") </del> detachError := errors.New("Fake detach error") diskCheckError := errors.New("Fake DiskIsAttached error") tests := []testcase{ // Successful Attach call { <del> name:   "Attach_Positive", attach: attachCall{diskName, nodeName, nil}, </del> <ins> name:           "Attach_Positive", diskIsAttached: diskIsAttachedCall{diskName, nodeName, false, diskCheckError}, attach:         attachCall{diskName, nodeName, nil}, </ins> test: func(testcase *testcase) (string, error) { attacher := newAttacher(testcase) return attacher.Attach(spec, nodeName)

expectedDevice: "/dev/disk/by-id/wwn-0x000000000", }, <del> // Attach call fails </del> <ins> // Disk is already attached </ins> { <del> name:   "Attach_Negative", attach: attachCall{diskName, nodeName, attachError}, </del> <ins> name:           "Attach_Positive_AlreadyAttached", diskIsAttached: diskIsAttachedCall{diskName, nodeName, false, diskCheckError}, attach:         attachCall{diskName, nodeName, nil}, </ins> test: func(testcase *testcase) (string, error) { attacher := newAttacher(testcase) return attacher.Attach(spec, nodeName) }, <del> expectedError: attachError, </del> <ins> expectedDevice: "/dev/disk/by-id/wwn-0x000000000", </ins> }, // Detach succeeds
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After start kubernetes controller manager, I get the following error: /--------------------- E0726 11:55:39. 1 ] Metric for serviceaccount_controller already registered /--------------------- What you expected to happen: successed to start kube-controller-manager service without error. How to reproduce it (as minimally and precisely as possible): every time. Anything else we need to know?: Environment: Kubernetes version (use ): v1.6.4 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
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
/kind support
fix it, close it.

Discussion:
maxRetries: maxRetries, } if cl != nil && cl.Core().RESTClient().GetRateLimiter() != nil { <del> metrics.RegisterMetricAndTrackRateLimiterUsage("serviceaccount_controller", cl.Core().RESTClient().GetRateLimiter()) </del> <ins> metrics.RegisterMetricAndTrackRateLimiterUsage("serviceaccount_tokens_controller", cl.Core().RESTClient().GetRateLimiter()) </ins> } e.serviceAccounts = serviceAccounts.Lister()
Change:
Causes failures in:
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 network /area platform/gce platform/gke

Discussion:
if strings.Contains(cfg.Global.NetworkName, "/") { networkURL = cfg.Global.NetworkName } else { <del> networkURL = gceNetworkURL(apiEndpoint, projectID, networkName) </del> <ins> networkURL = gceNetworkURL(apiEndpoint, projectID, cfg.Global.NetworkName) </ins> } }

gce := &GCECloud{ service:                  service, <ins> serviceAlpha:             serviceAlpha, </ins> serviceBeta:              serviceBeta, containerService:         containerService, cloudkmsService:          cloudkmsService,
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is not sent in a stable sort order. this makes node status patch requests larger than needed, and makes debugging nodes harder than necessary. What you expected to happen: stable sort of volumesInUse How to reproduce it (as minimally and precisely as possible): always Anything else we need to know?: nope Environment: n/a
/sig node
- this is a good getting started item.
I've already submitted a PR in . PTAL. Thanks.

Discussion:
import ( "fmt" <ins> "sort" </ins> "strconv" "time"

// volume *should* be attached to this node until it is safely unmounted. desiredVolumes := vm.desiredStateOfWorld.GetVolumesToMount() mountedVolumes := vm.actualStateOfWorld.GetGloballyMountedVolumes() <del> volumesToReportInUse := make( []v1.UniqueVolumeName, 0, /* len */ len(desiredVolumes)+len(mountedVolumes) /* cap */) desiredVolumesMap := make( map[v1.UniqueVolumeName]bool, len(desiredVolumes)+len(mountedVolumes) /* cap */) </del> <ins> volumesToReportInUse := make([]v1.UniqueVolumeName, 0, len(desiredVolumes)+len(mountedVolumes)) desiredVolumesMap := make(map[v1.UniqueVolumeName]bool, len(desiredVolumes)+len(mountedVolumes)) </ins> for _, volume := range desiredVolumes { if volume.PluginIsAttachable {

} } <ins> sort.Slice(volumesToReportInUse, func(i, j int) bool { return string(volumesToReportInUse[i]) < string(volumesToReportInUse[j]) }) </ins> return volumesToReportInUse }