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 20:54:55 +00:00
|
|
|
from consts import PROVISIONER_VERSION, PROVISIONER_NAME
|
2020-04-23 13:52:01 +00:00
|
|
|
from csi import csi_pb2, csi_pb2_grpc
|
2020-11-06 14:44:47 +00:00
|
|
|
from declarative import be_symlink, be_absent
|
2021-01-15 23:15:31 +00:00
|
|
|
from metrics import device_stats, mountpoint_to_dev
|
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 20:54:55 +00:00
|
|
|
name=PROVISIONER_NAME, 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
|
|
|
]
|
|
|
|
)
|
|
|
|
|
2020-09-11 16:14:40 +00:00
|
|
|
# @log_grpc_request
|
2020-04-23 13:52:01 +00:00
|
|
|
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
|
|
|
|
|
2020-09-11 16:14:40 +00:00
|
|
|
# @log_grpc_request
|
2020-04-23 13:52:01 +00:00
|
|
|
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):
|
2020-11-06 14:44:47 +00:00
|
|
|
target_path = request.target_path
|
2020-05-29 15:53:26 +00:00
|
|
|
staging_path = request.staging_target_path
|
2020-11-06 14:44:47 +00:00
|
|
|
staging_dev_path = Path(f"{staging_path}/dev")
|
|
|
|
be_symlink(path=target_path, to=staging_dev_path)
|
2020-04-23 13:52:01 +00:00
|
|
|
return csi_pb2.NodePublishVolumeResponse()
|
|
|
|
|
|
|
|
@log_grpc_request
|
|
|
|
def NodeUnpublishVolume(self, request, context):
|
2020-11-06 14:44:47 +00:00
|
|
|
target_path = request.target_path
|
|
|
|
be_absent(path=target_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
|
2020-11-06 14:44:47 +00:00
|
|
|
staging_dev_path = Path(f"{staging_path}/dev")
|
|
|
|
be_symlink(path=staging_dev_path, to=loop_file)
|
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
|
2020-11-06 14:44:47 +00:00
|
|
|
staging_dev_path = Path(f"{staging_path}/dev")
|
|
|
|
be_absent(staging_dev_path)
|
2020-05-29 15:53:26 +00:00
|
|
|
detach_loops(img_file)
|
|
|
|
return csi_pb2.NodeUnstageVolumeResponse()
|
|
|
|
|
2020-09-11 16:14:40 +00:00
|
|
|
# @log_grpc_request
|
2020-07-14 11:25:00 +00:00
|
|
|
def NodeGetVolumeStats(self, request, context):
|
2021-01-15 23:15:31 +00:00
|
|
|
volume_path = request.volume_path
|
|
|
|
dev = mountpoint_to_dev(volume_path)
|
|
|
|
stats = device_stats(dev=dev)
|
2020-07-14 11:25:00 +00:00
|
|
|
return csi_pb2.NodeGetVolumeStatsResponse(
|
|
|
|
usage=[
|
|
|
|
csi_pb2.VolumeUsage(
|
2020-11-06 14:44:47 +00:00
|
|
|
total=stats["dev_size"], unit=csi_pb2.VolumeUsage.Unit.BYTES,
|
2020-07-14 11:25:00 +00:00
|
|
|
),
|
|
|
|
]
|
|
|
|
)
|
|
|
|
|
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):
|
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-11-06 14:44:47 +00:00
|
|
|
volume_path = Path(volume_path).resolve()
|
|
|
|
run(f"losetup -c {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
|
|
|
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)}",
|
|
|
|
)
|
|
|
|
|
2020-11-06 14:44:47 +00:00
|
|
|
# FIXME: re-enable access_type after bd2fs is fixed
|
|
|
|
# access_type = volume_capability.WhichOneof("access_type")
|
|
|
|
# if access_type == "block":
|
|
|
|
# pass
|
|
|
|
# else:
|
|
|
|
# context.abort(
|
|
|
|
# grpc.StatusCode.INVALID_ARGUMENT,
|
|
|
|
# "PANIC! This should be handled by bd2fs!",
|
|
|
|
# )
|
2020-04-24 15:05:02 +00:00
|
|
|
|
2021-07-01 17:23:00 +00:00
|
|
|
MIN_SIZE = 16 * 1024 * 1024 # 16MiB: can't format xfs with smaller volumes
|
|
|
|
size = max(MIN_SIZE, request.capacity_range.required_bytes)
|
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-11-06 14:44:47 +00:00
|
|
|
init_rawfile.as_cmd(volume_id=request.name, size=size), 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,
|
|
|
|
)
|