Limitations of cloudkit

To ensure the proper functioning of cloudkit, consider its limitations when using this command line interface for IBM Storage Scale.

The limitations of cloudkit are:

Deleting a cluster may lead to failure if there are other resources that reference the resources created by cloudkit, or if there are additional resources sharing the network resources created by cloudkit that are not recognized by cloudkit.
To ensure the secure usage of the bastion private key, cloudkit fails to accept if the permissions of bastion private key is other than 400 or 600.
Cloudkit stores its states, temporary files, and logs under $HOME/scale-cloudkit, it is user's responsibility to replicate and keep it secure. If this metadata is lost, it cannot be reconstructed. However, loss of this metadata does not delete the resources on the cloud.
As part of a deployment made by using cloudkit, one namespace (file system) is configured per Storage-Only or Combined-compute-storage.
If any of the ebs volumes is detached and reattached after the initial cluster creation, these ebs volumes must be manually deleted after the cluster is destroyed.
Run grant from the same cloudkit version which is used to deploy the other resources like compute and storage cluster.
The cloudkit is currently limited to be executed as root user. Attempting to execute cloudkit as non root user, even with sudo privileges will result in failure.
While running an upgrade by using the cloudkit upgrade command, the interactive mode displays the possible upgrade versions for the targeted cluster.
Ensure to have the file system mounted after you perform edit operation. Use mmmount all -a command.
Edit operation on the cluster (that is, adding new nodes to an existing cluster) lacks automation for quorum node increase as per the node count change. Administrator must manually assign quorum roles to nodes based on the requirement.
Addition of new storage nodes creates new NSDs and adds them to the file system. This characteristic results in uneven distribution of data. The administrator needs to manually run the mmrestripefs -b command to distribute data to new disks
In the installer method based on AWS cloud VM, the installer VM must have its own security group, which must be different from the default security group that is created as part of VPC.
Cloud accounts come with a default network (VPC) that has a preconfigured subnet and security rules. Using VPC when performing an IBM Storage Scale cluster installation is not recommended. If you are using a new account, it is recommended to use the cloudkit create network command to create a network that works properly with IBM Storage Scale.
For IBM Storage Scale Developer Edition, the size for file system creation is limited to 12 TB per cluster.
Before using an instance type, you must ensure that it is available in the chosen availability zone across the respective cloud providers (AWS, GCP, Microsoft Azure).
The following Microsoft Azure resources cannot be filtered or viewable for reuse if they are created in resource groups that are different to the resource group that is operated by the cloudkit: DNS, key vault, encryption set controllers, images, network, and storage accounts.
If the file system version of a cluster was updated by using the mmchfs -V command, editing that upgraded cluster may fail.
IBM Storage Scale 5.2.2.0 introduces a new metadata field, which is called Deployment Purpose and offers two values to select from: Production and Non-Production. For clusters that are upgraded from previous releases to 5.2.2.0, this metadata field is automatically set as Production.
For GCP deployments, if the selected disk type is hyperdisk-throughput, the minimum disk size must be 2 TB.