Describe the bug
Block storage provisioning is not working when the host is commuting with IPv6 to the block API

Warning  ProvisioningFailed    10s (x3 over 22s)      block.csi.vultr.com_csi-vultr-controller-0_5df7f339-784b-49f2-9bda-5f1894bbe607  failed to provision volume with StorageClass "vultr-block-storage-hdd-retain": rpc error: code = Internal desc = {"error":"Unauthorized IP address: 2001:19f0:7002:xxx","status":401}

Where 2001:xxx is the main GUA of the node

To provision a volume, IPv6 has to get disabled first, then provision, then re-enable IPv6

To Reproduce
Steps to reproduce the behavior:

1. Enable IPv6 on the host
2. Try to provision block storage

Expected behavior

• Block storage provisioned

hi,

I have a doubt regarding the volume access mode, is it possible to implement "accessModes: ReadWriteMany " ?
If yes, how to do this?

What is the chosen license for this repository?

I have a volume that is unable to be detached with the following error:

time="2022-04-04T21:24:18Z" level=error msg="GRPC error: rpc error: code = Internal desc = cannot detach volume: {\"error\":\"Unable to detach block storage\",\"status\":400}" GRPC.call=/csi.v1.Controller/ControllerUnpublishVolume GRPC.request="volume_id:\"59cda749-b10d-4372-970d-6c91d3c52cd9\" node_id:\"ba14e0d5-df7f-4e31-94c5-78bb69778644\" "
time="2022-04-04T21:24:18Z" level=error msg="GRPC error: rpc error: code = Internal desc = cannot detach volume: {\"error\":\"Unable to detach block storage\",\"status\":400}" GRPC.call=/csi.v1.Controller/ControllerUnpublishVolume GRPC.request="volume_id:\"59cda749-b10d-4372-970d-6c91d3c52cd9\" node_id:\"ba14e0d5-df7f-4e31-94c5-78bb69778644\" "

Pod has been stopped and the container is stuck in Status: Terminating. Trying to delete it and I get the log messages above. I am generally able to release volumes but a few are stuck. Also tried deleting the volume in the UI but unable to detach it from the instance.

Can't really find a pattern with this so I am sorry if I am not giving all the information needed. Will also file a ticket with support and happy to follow up with more info.

Is your feature request related to a problem? Please describe.

I am trying to monitor PVs and am not able to get the kubelet_volume_stats_available_bytes because it is no longer supported by default in the node exporter.

Describe the solution you'd like

Include the metrics similar to how the AWS EBS CSI driver did it. I think CSI drivers themselves need to implement these metrics since k8s v1.13 or something around there though I could be wrong.

Issue: kubernetes-sigs/aws-ebs-csi-driver#524
PR: kubernetes-sigs/aws-ebs-csi-driver#677

Describe alternatives you've considered

I've been trying to get my relabel configs right to monitor a group of PVs and am not able to get the PV name out of the node exporter to be able to match node_filesystem_free_bytes to the right PV. This is broadly needed to monitor sensitive PVs running on VKE that might need volumes added to the array as they will up.

Describe the bug
Worker node is not able to have a volume mounted. The PVC is in a ready state and the volume exists however the volumeattachments.storage.k8s.io object is reporting ATTACHED=false with the message rpc error: code = DeadlineExceeded desc = context deadline exceeded.

This has happened multiple times in the last 2 weeks with both a newly created volume and an existing volume after a work load shift between nodes.

To Reproduce
Not exactly sure how to reproduce however the following is the description of the volumeattachment when the error occurs

Name:         csi-b1725867<REDACTED>
Namespace:    
Labels:       <none>
Annotations:  csi.alpha.kubernetes.io/node-id: d5b41b30-<REDACTED>
API Version:  storage.k8s.io/v1
Kind:         VolumeAttachment
Metadata:
  Creation Timestamp:  2022-11-18T09:47:38Z
  Finalizers:
    external-attacher/block-csi-vultr-com
  Managed Fields:
    API Version:  storage.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:csi.alpha.kubernetes.io/node-id:
        f:finalizers:
          .:
          v:"external-attacher/block-csi-vultr-com":
    Manager:      Go-http-client
    Operation:    Update
    Time:         2022-11-18T09:47:38Z
    API Version:  storage.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        f:attacher:
        f:nodeName:
        f:source:
          f:persistentVolumeName:
    Manager:      kube-controller-manager
    Operation:    Update
    Time:         2022-11-18T09:47:38Z
    API Version:  storage.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        f:attachError:
          .:
          f:message:
          f:time:
    Manager:         Go-http-client
    Operation:       Update
    Subresource:     status
    Time:            2022-11-18T22:18:15Z
  Resource Version:  11029444
  UID:               262caf1b-<REDACTED>
Spec:
  Attacher:   block.csi.vultr.com
  Node Name:  <REDACTED>
  Source:
    Persistent Volume Name:  pvc-<REDACTED>
Status:
  Attach Error:
    Message:  rpc error: code = DeadlineExceeded desc = context deadline exceeded
    Time:     2022-11-18T22:18:15Z
  Attached:   false
Events:       <none>

Expected behavior
When a PVC has been defined and the PV is created, the volume should be able to be mounted to a pod without issues.

Screenshots

Desktop (please complete the following information where applicable:

• OS - Vultr managed VKE cluster

Describe the bug

To Reproduce

1. Create a kubernetes cluster:
2. kubectl apply -f https://raw.githubusercontent.com/vultr/vultr-csi/master/docs/releases/latest.yml

Expected behavior

No errors

Describe the bug
The pvc remains pending after deployment. Logs showing 401 error when I run kubectl logs csi-vultr-controller-0 -n kube-system

To Reproduce
Steps to reproduce the behavior:

1. Deploy VKE cluster
2. kubectl apply -f https://raw.githubusercontent.com/vultr/vultr-csi/master/docs/releases/latest.yml
3. Deploy pvc

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: vultr-block-storage

Expected behavior
No error, pvc deployed and running.

Desktop (please complete the following information where applicable:

• OS: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-43-generic x86_64)
• Kubectl: Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.3", GitCommit:"434bfd82814af038ad94d62ebe59b133fcb50506", GitTreeState:"clean", BuildDate:"2022-10-12T10:57:26Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}
  Kustomize Version: v4.5.7
  Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.4", GitCommit:"95ee5ab382d64cfe6c28967f36b53970b8374491", GitTreeState:"clean", BuildDate:"2022-08-17T18:47:37Z", GoVersion:"go1.18.5", Compiler:"gc", Platform:"linux/amd64"}

Add any other context about the problem here.

Describe the bug
When the pvc is less than 10 Gb it throws error:

failed to provision volume with StorageClass "vultr-block-storage": rpc error: code = Internal desc = {"error":"Unable to add block storage: Failed to add block storage device. Invalid size (8GB) - Must be between 10GB and 10000GB.","status":400}

To Reproduce
Steps to reproduce the behavior:

1. Create a PVC of volume 8Gb
2. See error

Expected behavior
The PVC volume claim should either fix the volume to 10Gb or should create volume as per the claim.

Screenshots
This makes it in pending state.

problem here.

Describe the bug
Many charts attempt to create PVCs with a size of less than 10GiB. This will fail because Vultr does not support smaller volumes than this.

To Reproduce
Steps to reproduce the behavior:

1. Deploy the gitlab/gitlab chart
2. Postgres, Redis, and Prometheus fail to start as the PVCs can't be created

Expected behavior
Deploying charts should work out of the box

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information where applicable:

• VKE v1.20.11+2

Additional context
I understand that this is not a bug with the CSI, but I am posting it here as it took me a while to figure out what was wrong.

https://github.com/vultr/vultr-csi/tree/4778ab2382ea56d30beffdd179280ca8b9953580/docs/kubernetes#hdd-block-type

It says expect in bold. I couldn't help but notice. 🙂

Describe the bug
Upgraded from 1.23.x to the latest 1.23.x VKE.

After the upgrade, volumes stopped attaching to pods.
"rpc error: code = NotFound desc = cannot get volume: gave up after 1 attempts, last error : context deadline exceeded"

To Reproduce
Existing workloads, unmodified.

Upgrade from 1.23.8? (I think) to 1.23.14 (latest 1.23.x)

Expected behavior
Continued functionality

Screenshots

Description
The current Twitter icon on our website appears to be outdated or incorrect. This issue is raised to track and address the update of the Twitter icon to ensure that it aligns with our branding and remains visually appealing.

Current State
Describe the current state of the Twitter icon on the website. Specify if it's outdated, incorrect, or if there are any issues with its appearance.
Marked in screenshot below.

Desired Changes
New Icon: Provide a link or upload the new Twitter icon that should replace the current one.
Styling: If there are specific styling considerations (size, color, etc.), mention them here.
Example Code
If applicable, include code snippets related to updating the Twitter icon in the website's codebase.

Benefits
Keep the website's visual elements up-to-date.
Ensure consistency with our branding across all platforms.
Additional Notes
Double-check the licensing and permissions for the new icon.
Coordinate with the design team or responsible individuals for approval

I haven't tried this yet. But from the project README, I couldn't see anything related to selecting where the Block Storage (BS) should be located. From Vultr.com web UI, I saw 2 locations for BS.

Can I define the BS location e.g. Los Angeles via Kubernetes YAML manifest?

Is Nomad support planned?

In theory it should work out of the box, but in practice many plugins are built with K8S in mind and do not adhere to csi specification.

I'm planning to test in very soon and I will share the result and, if it works, a deployment example.

Update CSI dependencies

Does this storage driver have the ability to change the file system format like ext4, xfs, zfs, etc?

Which file types are supported?

Brad

Is your feature request related to a problem? Please describe.
Currently the Vultr CSI doesnt allows resizing PVCs as needed. It would be beneficial to allow PVCs to be expanded as required to help customers manage costs.

Describe the solution you'd like
Vultr CSI processes requests to change provisioned volume based on the allowVolumeExpansion storage class option.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: vultr-block-storage-resizable
parameters:
  block_type: high_perf
provisioner: block.csi.vultr.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true  # <--- here

Describe alternatives you've considered
The only way around this is to use a storage class backed by another CSI either external to Vultr or deployed on other Vultr infra.

Extra information
Below is the current output when creating another storage class using the Vultr CSI with allowVolumeExpansion enabled then editing the PVC for expansion.

Events:
  Type     Reason                 Age                From                                                                             Message
  ----     ------                 ----               ----                                                                             -------
  Normal   Provisioning           19m                block.csi.vultr.com_csi-vultr-controller-0_8864b530-9d56-4b1e-8f66-95f458a43e56  External provisioner is provisioning volume for claim "testing-pvc/testing-pvc"
  Normal   ProvisioningSucceeded  19m                block.csi.vultr.com_csi-vultr-controller-0_8864b530-9d56-4b1e-8f66-95f458a43e56  Successfully provisioned volume pvc-0761d6f94e434df6
  Warning  ExternalExpanding      4m37s              volume_expand                                                                    Ignoring the PVC: didn't find a plugin capable of expanding the volume; waiting for an external controller to process this PVC.

Docker Swarm is now supporting CSI. It would be great to have this available on Vultr for running lighter cluster workloads without being limited by bind mounts.

Moby documentation is available here. Some potentially useful examples are available here.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

Describe the bug
Using rook.io, the rook pods rook-ceph-osd-prepare- fails to setup a PersistentVolumeClaim.

"describe pod" finally reports the event (warning) "MapVolume.SetUpDevice failed for volume "pvc-c869a0057b0c4904" : kubernetes.io/csi: blockMapper.stageVolumeForBlock failed to check STAGE_UNSTAGE_VOLUME capability: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/lib/kubelet/plugins/block.csi.vultr.com/csi.sock: connect: connection refused"" from the kubelet.

To Reproduce
Steps to reproduce the behavior:
(NOTE: This setup works fine on Azure AKS, with only the storageClassName adjusted.)

1. Create a fresh kubernetes cluster (probably 1 worker node is sufficient for reproduction)
2. For basic Rook setup: From the files in https://github.com/rook/rook/tree/master/deploy/examples, run kubectl apply -f for crds.yaml, common.yaml and operator.yaml, this creates CRDs, Roles and a rook-ceph-operator deployment/pod
3. Run kubectl apply -f for the following CephCluster yaml:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    # NOTE: see cluster.yaml in <https://github.com/rook/rook.git> for up-to-date image version 
    image: quay.io/ceph/ceph:v17.2.1
    allowUnsupported: false
  dataDirHostPath: /var/lib/rook
  skipUpgradeChecks: false
  continueUpgradeAfterChecksEvenIfNotHealthy: false
  waitTimeoutForHealthyOSDInMinutes: 10
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    count: 2
    allowMultiplePerNode: false
    modules:
      - name: pg_autoscaler
        enabled: true
  dashboard:
    enabled: true
    ssl: true
  storage:
   storageClassDeviceSets:
    - name: set1
      # NOTE: change this to the number of nodes that should host an OSD
      count: 1
      portable: false
      tuneDeviceClass: false
      encrypted: false
      volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          storageClassName: vultr-block-storage-hdd
          accessModes:
            - ReadWriteOnce
          # NOTE: rook seems to expect a raw, unmounted device "volumeMode: Block"
          volumeMode: Block
          resources:
            requests:
              storage: 40Gi

4. See events in kubectl -n rook-ceph describe pod rook-ceph-osd-prepare-* after the pod(s) got stuck.

Expected behavior
The pods rook-ceph-osd-prepare-* should disappear after a short time, and instead corresponding rook-ceph-osd-* pods (without -prepare-) should remain.

Additional context
I was using VKE with Kubernetes 1.23.x.