Skip to content

Commit

Permalink
test(features): add missing bdd
Browse files Browse the repository at this point in the history 
Signed-off-by: sinhaashish <[email protected]>
  • Loading branch information
@sinhaashish
sinhaashish committed Jul 29, 2024
1 parent 4fbf85d commit c389127
Showing 1 changed file with 129 additions and 16 deletions.
145 changes: 129 additions & 16 deletions tests/bdd/zfs.feature
View file
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs

Scenario Outline: Volume property change
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class with a deployment using the same pvc
And pvc is created referencing this storage class and a deployment using the same pvc
When the zfsvolume properties like <properties> are updated
Then the zfsvolume properties must reflect the updated value
Examples:
Expand All @@ -49,7 +49,7 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs

Scenario Outline: Volume data size change
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class with a deployment using the same pvc
And pvc is created referencing this storage class and a deployment using the same pvc
When the zfsvolume volume type is <volume_type> and record size is updated to <record_size> and volume block size to <block_size> size is updated
Then the volume type is <volume_type> must have the record sise as <record_size> and volume block size as <block_size> size
Examples:
Expand All @@ -65,7 +65,7 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs

Scenario Outline: Create a snapshot from a pvc
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class with a deployment using the same pvc
And pvc is created referencing this storage class and a deployment using the same pvc
And a zfsvolume is created and used by the application
When the snapshot create command for the given pvc is run in the same namespace
Then the snapshot must be created for the corresponding pvc with status as ready to use
Expand All @@ -78,7 +78,7 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs

Scenario Outline: Create a clone from a <source>
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class with a deployment using the same pvc
And pvc is created referencing this storage class and a deployment using the same pvc
And a zfsvolume is created and used by the application
And a snapshot is be created for the corresponding pvc
When the clone create command is run for this snapshot and a deployment is created to use this clone
Expand All @@ -96,7 +96,7 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs

Scenario Outline: Resize of pvc
Given a storage class is created with fsType as <fsType>
And pvc is created referencing the this storage class with a deployment using the same pvc
And pvc is created referencing the this storage class and a deployment using the same pvc
When the size of pvc is update to a <new_capacity>
Then the pvc must be of size <new_capacity>
Examples:
Expand All @@ -112,16 +112,6 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs
When a deployment is created using the same pvc
Then zfsvolume must be created and used by the application

Scenario Outline: Volume property change for a raw block volume
Given a storage class is created without any fstype
And a pvc with volumeMode as Bolck is created referencing this storage class
When a deployment is created using the same pvc
When the zfsvolume properties <properties> are updated
Then the zfsvolume properties must reflect the changed value for the <properties>
Examples:
| properties |
| compression |
| dedup |

Scenario Outline: Volume data size change for a raw block volume
Given a storage class is created without any fstype
Expand All @@ -139,4 +129,127 @@ Feature: Validate volume provisioning for fsType zfs, ext4, xfs, btrfs
| ZVOL | 8192 | 16384 |
| ZVOL | 8192 | 16384 |


Scenario Outline: Online volume resize
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class
And a deployment is created using the same pvc which is in running state
When resize volume requested is by updating the PVC resource
Then corresponding pvc must be resized
Examples:
| fsType |
| zfs |
| ext4 |
| xfs |

Scenario Outline: Thin provisioning
Given a storage class is created with fsType as <fsType> and thinprovision as true
And pvc is created referencing this storage class and a deployment using the same pvc
And a zfsvolume is created and used by the application
When the ZPOOL size is 1GB and the requested storage in PVC is 10 GB
Then the volume must be provisioned even if the ZPOOL does not have the enough capacity
Examples:
| fsType |
| zfs |
| ext4 |
| xfs |
| btrfs |

Scenario Outline: Supported compression algorithm
Given a storage class is created with fsType as zfs, ext4, xfs, btrfs and compression as <compression_type>
And pvc is created referencing this storage class and a deployment using the same pvc
When the zfsvolume compression is present
Then the volume ust be provisioned and the compression type of volume must be <compression_type>
Examples:
| compression_type|
| lzjb |
| zstd |
| zstd-1 |
| zstd-2 |
| zstd-3 |
| zstd-4 |
| zstd-5 |
| zstd-7 |
| zstd-8 |
| zstd-9 |
| zstd-10 |
| zstd-11 |
| zstd-12 |
| zstd-13 |
| zstd-14 |
| zstd-15 |
| zstd-16 |
| zstd-17 |
| zstd-18 |
| zstd-19 |
| gzip |
| gzip-1 |
| gzip-2 |
| gzip-3 |
| gzip-4 |
| gzip-5 |
| gzip-6 |
| gzip-7 |
| gzip-8 |
| gzip-9 |
| zle |
| lz4 |

############################################################################################################
################## The below bdd need to be implemented in ci tests ########################################
############################################################################################################

Scenario Outline: Create a clone from a <source>
Given a storage class is created without any fstype as Raw block volume does not have any fstype
And a pvc with volumeMode as Bolck is created referencing this storage class
And a deployment is created using the same pvc
And a snapshot is be created for the corresponding <source>
When the clone create command is run for this snapshot and a deployment is created to use this clone
Then the clone must be created from the snapshot and the created deployment must use the cloned volume
Examples:
| source |
| snapshot |
| volume |

Scenario Outline: Shared volume
Given a storage class is created with fsType as <fsType> and shared is set to yes
And pvc is created referencing this storage class and a deployment using the same pvc
And a zfsvolume is created and used by the application
When two pods were deployed on same node and they both are running
Then the LocalPV-ZFS Driver will allow the volumes to be mounted by more than one pods
Examples:
| fsType |
| zfs |
| ext4 |
| xfs |
| btrfs |


############################################################################################################
################## The below bdd need to be implemented in e2e tests ########################################
############################################################################################################

Scenario Outline: Allowed topologies
Given a storage class with allowedTopologies is created with fsType as <fsType>
And pvc is created referencing this storage class and a deployment using the same pvc
When the topology for specific zpool is defined in the storage class
Then the volumes must be provisioned on the nodes which has the required zpool
Examples:
| fsType |
| zfs |
| ext4 |
| xfs |
| btrfs |

Scenario Outline: Import Existing Volumes to LocalPV-ZFS
Given a storage class is created with fsType as <fsType>
And pvc is created referencing this storage class and a deployment using the same pvc
When a node fails and the disks is attached to a different node
Then the zfs pool should be imported on that pool
And the zfsvolume resource should reflect that upon creation of a volume referencing the pool on that node
And the application should keep running
Examples:
| fsType |
| zfs |
| ext4 |
| xfs |
| btrfs |

0 comments on commit c389127

Please sign in to comment.