2020-05-29 15:53:26 +00:00
|
|
|
from pathlib import Path
|
|
|
|
|
2020-04-24 15:05:02 +00:00
|
|
|
import grpc
|
2020-04-23 13:52:01 +00:00
|
|
|
from google.protobuf.wrappers_pb2 import BoolValue
|
|
|
|
|
2020-04-24 15:38:18 +00:00
|
|
|
import rawfile_util
|
2020-08-14 15:35:50 +00:00
|
|
|
from consts import PROVISIONER_VERSION
|
2020-04-23 13:52:01 +00:00
|
|
|
from csi import csi_pb2, csi_pb2_grpc
|
2020-06-13 23:47:32 +00:00
|
|
|
from declarative import be_mounted, be_unmounted, be_symlink, be_absent
|
2020-07-14 11:25:00 +00:00
|
|
|
from metrics import volume_stats
|
2020-04-24 11:48:09 +00:00
|
|
|
from orchestrator.k8s import volume_to_node, run_on_node
|
2020-05-29 15:53:26 +00:00
|
|
|
from rawfile_util import attach_loop, detach_loops
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
from remote import init_rawfile, scrub, expand_rawfile
|
2020-04-24 15:38:18 +00:00
|
|
|
from util import log_grpc_request, run
|
2020-04-23 13:52:01 +00:00
|
|
|
|
|
|
|
NODE_NAME_TOPOLOGY_KEY = "hostname"
|
|
|
|
|
|
|
|
|
|
|
|
class RawFileIdentityServicer(csi_pb2_grpc.IdentityServicer):
|
|
|
|
@log_grpc_request
|
|
|
|
def GetPluginInfo(self, request, context):
|
|
|
|
return csi_pb2.GetPluginInfoResponse(
|
2020-08-14 15:35:50 +00:00
|
|
|
name="rawfile.hamravesh.com", vendor_version=PROVISIONER_VERSION
|
2020-04-23 13:52:01 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def GetPluginCapabilities(self, request, context):
|
|
|
|
Cap = csi_pb2.PluginCapability
|
|
|
|
return csi_pb2.GetPluginCapabilitiesResponse(
|
|
|
|
capabilities=[
|
|
|
|
Cap(service=Cap.Service(type=Cap.Service.CONTROLLER_SERVICE)),
|
|
|
|
Cap(
|
|
|
|
service=Cap.Service(
|
|
|
|
type=Cap.Service.VOLUME_ACCESSIBILITY_CONSTRAINTS
|
|
|
|
)
|
|
|
|
),
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
Cap(
|
|
|
|
volume_expansion=Cap.VolumeExpansion(
|
|
|
|
type=Cap.VolumeExpansion.ONLINE
|
|
|
|
)
|
|
|
|
),
|
2020-04-23 13:52:01 +00:00
|
|
|
]
|
|
|
|
)
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def Probe(self, request, context):
|
|
|
|
return csi_pb2.ProbeResponse(ready=BoolValue(value=True))
|
|
|
|
|
|
|
|
|
|
|
|
class RawFileNodeServicer(csi_pb2_grpc.NodeServicer):
|
|
|
|
def __init__(self, node_name):
|
|
|
|
self.node_name = node_name
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodeGetCapabilities(self, request, context):
|
2020-05-29 15:53:26 +00:00
|
|
|
Cap = csi_pb2.NodeServiceCapability
|
|
|
|
return csi_pb2.NodeGetCapabilitiesResponse(
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
capabilities=[
|
|
|
|
Cap(rpc=Cap.RPC(type=Cap.RPC.STAGE_UNSTAGE_VOLUME)),
|
2020-07-14 11:25:00 +00:00
|
|
|
Cap(rpc=Cap.RPC(type=Cap.RPC.GET_VOLUME_STATS)),
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
Cap(rpc=Cap.RPC(type=Cap.RPC.EXPAND_VOLUME)),
|
|
|
|
]
|
2020-05-29 15:53:26 +00:00
|
|
|
)
|
2020-04-23 13:52:01 +00:00
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodePublishVolume(self, request, context):
|
|
|
|
mount_path = request.target_path
|
2020-05-29 15:53:26 +00:00
|
|
|
staging_path = request.staging_target_path
|
2020-06-13 23:47:32 +00:00
|
|
|
be_mounted(dev=f"{staging_path}/device", mountpoint=mount_path)
|
2020-04-23 13:52:01 +00:00
|
|
|
return csi_pb2.NodePublishVolumeResponse()
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodeUnpublishVolume(self, request, context):
|
|
|
|
mount_path = request.target_path
|
2020-06-13 23:47:32 +00:00
|
|
|
be_unmounted(mount_path)
|
2020-04-23 13:52:01 +00:00
|
|
|
return csi_pb2.NodeUnpublishVolumeResponse()
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodeGetInfo(self, request, context):
|
|
|
|
return csi_pb2.NodeGetInfoResponse(
|
|
|
|
node_id=self.node_name,
|
|
|
|
accessible_topology=csi_pb2.Topology(
|
|
|
|
segments={NODE_NAME_TOPOLOGY_KEY: self.node_name}
|
|
|
|
),
|
|
|
|
)
|
|
|
|
|
2020-05-29 15:53:26 +00:00
|
|
|
@log_grpc_request
|
|
|
|
def NodeStageVolume(self, request, context):
|
|
|
|
img_file = rawfile_util.img_file(request.volume_id)
|
|
|
|
loop_file = attach_loop(img_file)
|
|
|
|
staging_path = request.staging_target_path
|
|
|
|
device_path = Path(f"{staging_path}/device")
|
2020-06-13 23:47:32 +00:00
|
|
|
be_symlink(path=device_path, to=loop_file)
|
2020-05-29 15:53:26 +00:00
|
|
|
mount_path = Path(f"{staging_path}/mount")
|
2020-06-13 23:47:32 +00:00
|
|
|
mount_path.mkdir(exist_ok=True)
|
|
|
|
be_mounted(dev=device_path, mountpoint=mount_path)
|
2020-05-29 15:53:26 +00:00
|
|
|
return csi_pb2.NodeStageVolumeResponse()
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodeUnstageVolume(self, request, context):
|
|
|
|
img_file = rawfile_util.img_file(request.volume_id)
|
|
|
|
staging_path = request.staging_target_path
|
|
|
|
mount_path = Path(f"{staging_path}/mount")
|
2020-06-13 23:47:32 +00:00
|
|
|
be_unmounted(mount_path)
|
|
|
|
be_absent(mount_path)
|
2020-05-29 15:53:26 +00:00
|
|
|
device_path = Path(f"{staging_path}/device")
|
2020-06-13 23:47:32 +00:00
|
|
|
be_absent(device_path)
|
2020-05-29 15:53:26 +00:00
|
|
|
detach_loops(img_file)
|
|
|
|
return csi_pb2.NodeUnstageVolumeResponse()
|
|
|
|
|
2020-07-14 11:25:00 +00:00
|
|
|
@log_grpc_request
|
|
|
|
def NodeGetVolumeStats(self, request, context):
|
|
|
|
volume_id = request.volume_id
|
|
|
|
stats = volume_stats(volume_id)
|
|
|
|
return csi_pb2.NodeGetVolumeStatsResponse(
|
|
|
|
usage=[
|
|
|
|
csi_pb2.VolumeUsage(
|
|
|
|
available=stats["fs_free"],
|
|
|
|
total=stats["fs_size"],
|
|
|
|
used=stats["fs_size"] - stats["fs_free"],
|
|
|
|
unit=csi_pb2.VolumeUsage.Unit.BYTES,
|
|
|
|
),
|
|
|
|
csi_pb2.VolumeUsage(
|
|
|
|
available=stats["fs_files_free"],
|
|
|
|
total=stats["fs_files"],
|
|
|
|
used=stats["fs_files"] - stats["fs_files_free"],
|
|
|
|
unit=csi_pb2.VolumeUsage.Unit.INODES,
|
|
|
|
),
|
|
|
|
]
|
|
|
|
)
|
|
|
|
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
@log_grpc_request
|
|
|
|
def NodeExpandVolume(self, request, context):
|
|
|
|
volume_id = request.volume_id
|
2020-07-12 17:47:29 +00:00
|
|
|
volume_path = request.volume_path
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
size = request.capacity_range.required_bytes
|
2020-07-12 17:47:29 +00:00
|
|
|
fs_type = rawfile_util.metadata(volume_id)["fs_type"]
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
img_file = rawfile_util.img_file(volume_id)
|
|
|
|
for dev in rawfile_util.attached_loops(img_file):
|
|
|
|
run(f"losetup -c {dev}")
|
2020-07-12 17:47:29 +00:00
|
|
|
if fs_type == "ext4":
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
run(f"resize2fs {dev}")
|
2020-07-12 17:47:29 +00:00
|
|
|
elif fs_type == "btrfs":
|
|
|
|
run(f"btrfs filesystem resize max {volume_path}")
|
|
|
|
else:
|
|
|
|
raise Exception(f"Unsupported fsType: {fs_type}")
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
break
|
|
|
|
return csi_pb2.NodeExpandVolumeResponse(capacity_bytes=size)
|
|
|
|
|
2020-04-23 13:52:01 +00:00
|
|
|
|
|
|
|
class RawFileControllerServicer(csi_pb2_grpc.ControllerServicer):
|
|
|
|
@log_grpc_request
|
|
|
|
def ControllerGetCapabilities(self, request, context):
|
|
|
|
Cap = csi_pb2.ControllerServiceCapability
|
|
|
|
return csi_pb2.ControllerGetCapabilitiesResponse(
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
capabilities=[
|
|
|
|
Cap(rpc=Cap.RPC(type=Cap.RPC.CREATE_DELETE_VOLUME)),
|
|
|
|
Cap(rpc=Cap.RPC(type=Cap.RPC.EXPAND_VOLUME)),
|
|
|
|
]
|
2020-04-23 13:52:01 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def CreateVolume(self, request, context):
|
|
|
|
# TODO: volume_capabilities
|
2020-04-24 15:05:02 +00:00
|
|
|
|
|
|
|
if len(request.volume_capabilities) != 1:
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT, "Exactly one cap is supported"
|
|
|
|
)
|
|
|
|
|
|
|
|
volume_capability = request.volume_capabilities[0]
|
|
|
|
|
|
|
|
AccessModeEnum = csi_pb2.VolumeCapability.AccessMode.Mode
|
|
|
|
if volume_capability.access_mode.mode not in [
|
|
|
|
AccessModeEnum.SINGLE_NODE_WRITER
|
|
|
|
]:
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT,
|
|
|
|
f"Unsupported access mode: {AccessModeEnum.Name(volume_capability.access_mode.mode)}",
|
|
|
|
)
|
|
|
|
|
|
|
|
access_type = volume_capability.WhichOneof("access_type")
|
|
|
|
if access_type == "mount":
|
2020-07-12 17:47:29 +00:00
|
|
|
fs_type = volume_capability.mount.fs_type
|
|
|
|
if fs_type == "":
|
|
|
|
fs_type = "ext4"
|
2020-04-24 15:05:02 +00:00
|
|
|
elif access_type == "block":
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT, "Block mode not supported (yet)"
|
|
|
|
)
|
|
|
|
else:
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT, f"Unknown access type: {access_type}"
|
|
|
|
)
|
|
|
|
|
2020-04-24 11:48:09 +00:00
|
|
|
size = request.capacity_range.required_bytes
|
2020-04-24 15:38:18 +00:00
|
|
|
size = max(size, 10 * 1024 * 1024) # At least 10MB
|
2020-04-24 15:05:02 +00:00
|
|
|
|
|
|
|
try:
|
|
|
|
node_name = request.accessibility_requirements.preferred[0].segments[
|
|
|
|
NODE_NAME_TOPOLOGY_KEY
|
|
|
|
]
|
|
|
|
except IndexError:
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT,
|
|
|
|
"No preferred topology set. Is external-provisioner running in strict-topology mode?",
|
|
|
|
)
|
|
|
|
except KeyError:
|
|
|
|
context.abort(
|
|
|
|
grpc.StatusCode.INVALID_ARGUMENT, "Topology key not found... why?"
|
|
|
|
)
|
2020-04-24 11:48:09 +00:00
|
|
|
|
|
|
|
run_on_node(
|
2020-07-12 17:47:29 +00:00
|
|
|
init_rawfile.as_cmd(volume_id=request.name, size=size, fs_type=fs_type),
|
|
|
|
node=node_name,
|
2020-04-24 11:48:09 +00:00
|
|
|
)
|
|
|
|
|
2020-04-23 13:52:01 +00:00
|
|
|
return csi_pb2.CreateVolumeResponse(
|
|
|
|
volume=csi_pb2.Volume(
|
|
|
|
volume_id=request.name,
|
2020-04-24 11:48:09 +00:00
|
|
|
capacity_bytes=size,
|
2020-04-23 13:52:01 +00:00
|
|
|
accessible_topology=[
|
|
|
|
csi_pb2.Topology(segments={NODE_NAME_TOPOLOGY_KEY: node_name})
|
|
|
|
],
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def DeleteVolume(self, request, context):
|
2020-04-24 11:48:09 +00:00
|
|
|
node_name = volume_to_node(request.volume_id)
|
|
|
|
run_on_node(scrub.as_cmd(volume_id=request.volume_id), node=node_name)
|
2020-04-23 13:52:01 +00:00
|
|
|
return csi_pb2.DeleteVolumeResponse()
|
Support online volume expansion
Summary:
Online volume expansion is a 2 phase process:
1. The backing storage, in this case the raw file, needs to be resized. (i.e. `truncate -s`)
2. The node should be notified, so that it can both refresh its device capacity (i.e. `losetup -c`) and resize the filesystem (`resize2fs`) accordingly.
Although in our case both steps could be performed on the node itself, for the sake of following the semantics of how volume expansion works, we perform step 1 from the controller, and step 2 from the node.
Also, the `external-resizer` component is added which watches for PVC size updates, and notifies the CSI controller about it.
Test Plan:
Setup:
- Deploy
- Create a rawfile-backed pvc, and attach a Deployment to it
- Keep an eye on `rawfile` pod logs in `kube-system` namespace to see if any errors pop out during all scenarios
Scenario 1:
- Increase the size of the pvc
- Exec into the pod and verify that the volume is resized indeed (using `df`)
Scenario 2:
- Decrease deployment's replica to 0
- Increase the size of the pvc. Wait for a couple of minutes.
- Increase deployment's replica to 1
- Exec into the pod and verify that the volume is resized indeed.
Reviewers: bghadiri, mhyousefi, h.marvi, sina_rad
Reviewed By: bghadiri, mhyousefi, sina_rad
Differential Revision: https://phab.hamravesh.ir/D817
2020-06-12 12:12:49 +00:00
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def ControllerExpandVolume(self, request, context):
|
|
|
|
volume_id = request.volume_id
|
|
|
|
node_name = volume_to_node(volume_id)
|
|
|
|
size = request.capacity_range.required_bytes
|
|
|
|
run_on_node(
|
|
|
|
expand_rawfile.as_cmd(volume_id=volume_id, size=size), node=node_name
|
|
|
|
)
|
|
|
|
|
|
|
|
return csi_pb2.ControllerExpandVolumeResponse(
|
|
|
|
capacity_bytes=size, node_expansion_required=True,
|
|
|
|
)
|