Restoring from a snapshot to a larger size

[msau42]

Today, what happens with many block-based plugins is that the disk will be created at the larger size, but the filesystem (from the snapshot) is at the smaller size. Filesystem expansion won't be triggered because PV is created at the requested PVC size.

We discussed this at the csi standup last week and agreed that the behavior should be:

• If a plugin is not going to resize the filesystem during the restore from snapshot operation, then they should return the original snapshot size (the original block size), so that the resize operation can be done.
• If a plugin is going to resize everything as part of restore, including the filesystem, then they should return the new size.
• If the plugin returns nothing (because size is optional today), then we continue the same behavior of setting the pv to the new size regardless.

This bug can track the following aspects:

• Do we need to clarify anything in the CSI spec?
• Make sure external-provisioner is doing the right thing, and we have unit tests
• Update mock driver and add e2e tests for the different scenarios
• Add generic e2e test that can be used by all plugins

Updating individual csi drivers to return the proper behavior can be tracked separately.

[msau42]

/kind bug

cc @jsafrane @gnufied @xing-yang @bswartz

[msau42]

Another open issue: should we apply the same logic to clone?

[msau42]

cc @j-griffith

[msau42]

@Jiawei0227 will help take a look at implementing this

[gnufied]

issue @jsafrane created in k/k repo has summary of discussion so far - kubernetes/kubernetes#94929

[bswartz]

The text from the CreateVolumeRequest message in the spec says:

// This field is OPTIONAL. This allows the CO to specify the capacity
// requirement of the volume to be provisioned. If not specified, the
// Plugin MAY choose an implementation-defined capacity range. If
// specified it MUST always be honored, even when creating volumes
// from a source; which MAY force some backends to internally extend
// the volume after creating it.
CapacityRange capacity_range = 2;

The current implication is that any expansions are magically taken care of inside the CreateVolume call. We definitely need spec language here clarifying that while the new size must be honored insofar as the controller's notion of the volume size, the CO may need to do the NodeExpand portion of the work to bring the node's notion of the volume size into sync.

[Jiawei0227]

There is currently a discussion here: container-storage-interface/spec#452
I will start to implement this as soon as we get the final decision on how the CO and SP should behave.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Jiawei0227]

/remove-lifecycle stale

I am grooming my backlog and found this one. It seems from the last CSI meeting, we decide that to let each CSI driver to handle it. They should call the expand. So I guess there is no more work involved in the csi-provisioner for now?

[xing-yang]

I am grooming my backlog and found this one. It seems from the last CSI meeting, we decide that to let each CSI driver to handle it. They should call the expand. So I guess there is no more work involved in the csi-provisioner for now?

Yes. CSI driver needs to handle this. @jsafrane has updated the CSI spec PR: container-storage-interface/spec#452

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jsafrane]

/reopen

[k8s-ci-robot]

@jsafrane: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jsafrane]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[xing-yang]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[humblec]

@msau42 @xing-yang @jsafrane afaict, this is handled in provisioner code already and I am closing this issue. Please reopen if required.
/close

[amacaskill]

@humblec Could you please point to where in the provisioner code this is handled?

[msau42]

@amacaskill the conclusion of this bug is that each CSI driver needs to make changes to their NodeStage/NodePublish implementations to resize the filesystem if possible. See https://github.com/container-storage-interface/spec/pull/452/files for the spec clarification and https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/595/files for an example. Resize utilities have been exported in https://github.com/kubernetes/kubernetes/pull/99088/files so that CSI drivers can share similar logic.

For pd csi driver it looks like it was added in kubernetes-sigs/gcp-compute-persistent-disk-csi-driver#972

[humblec]

@amacaskill addition to what @msau42 mentioned above, this make sure the controller allows to have a capacity >= snapshot ->restore size. https://github.com/kubernetes-csi/external-provisioner/blob/master/pkg/controller/controller.go#L1134