Once clusters are attached to CF, you can manage the volumes and snapshots of the configured project using CF via cfcli or its API.
Below are some useful examples.
Example 1:
Create a volume in the project 'my-project', with the volume name 'vol', maximum capacity '10gib', acl: 'ALLOW_ANY', and replica count: '3':
cfcli create volume --project-name my-project --name vol --size 10gib --replica-count 3 --acl ALLOW_ANYExample 2:
Create a snapshot in the project "my-project", with the snapshot name: "snap", source volume uuid: {volume-uuid}, and description snapshot-description:
fcli create snapshot --project-name my-project --name snap --source-volume-uuid {volume-uuid} --description a-snapshot-description --retention-time 7200sExample 3:
List all volumes:
cfcli list volumesExample 4:
Update a volume in the project "my-project", with the volume name "vol", to new maximum capacity: "20 Gib":
cfcli update volume --project-name my-project --name vol --size 20GibThe CF managed project must exist in the attached LB clusters - otherwise this cluster will not be used by CF for executing the required request.
Changing the Project Name
CF can manage storage objects of a single tenant (project). The project can be determined at deployment time (passed as input when running the deployment script input or in the Ansible files if manually run).
You can change the project name later on the CF machine. Perform the following steps to do so:
- Open the
/etc/cf/cf.ymlfile for editing. - Replace the value for the “projectName” field with the new project name.
- Save the file.
- Restart the cluster-federation service:
docker restart cluster-federation
Changing the project name will result in CF managing other storage objects (volumes and snapshots that belong to a different project). This effectively means that CF will not display the previous objects nor allow it to create, update, or delete objects that belong to the previous project. Use this feature with caution.
Timeouts
The CF service has explicit connection timeouts defined to ensure resource stability and predictable performance under high load. The service enforces a maximum processing and response time of 60 seconds for any client request.
If the service takes less than 60 seconds to process the request, the connection remains open, and a response is received normally. If the service takes more than 60 seconds to process the request, the service will terminate the connection precisely at the 60-second mark, and the client will receive a connection closure error (regardless of the client-side timeout setting).
We recommend configuring the client applications to use a request timeout of 60 seconds or less, to align with the server's behavior and enable faster retry logic.