Hi, I'd like to draw the attention to some of the more operational
aspects of this feature, mainly the storage appliance internals and UI.
So long story short, I've discussed with Abhisar and others and we'll be
deploying a VM based on the Cloudstack Debian systemvm template which
will export NFS v3/4 for user VMs to consume.
Below are some of the more finer details, please have a read if you are
interested in this feature and feel free to comment and make
suggestions.
1 - The appliance will only have a single export, that export will be a
single disk (data volume). Keep it simple.
2 - GPT partition table and a single partition, filesystem probably XFS
and/or customisable - something stock Debian supports, simple and boring
stuff.
3 - NFS export should be simple, we can standardise on a path name eg
/nfs or /fileshare and it will be identical on all appliances.
4 - Starting specs: 2 cores, 4 GB RAM - should be OK for a small NFS
server, the appliance can be upgraded to bigger offerings.
5 - Disk offering should be flagged accordingly, the disk offering will
have a flag/checkbox for "storage appliance" use.
6 - This appliance will not be a system VM, it will be a "blackbox", but
the approach will be similar here to CKS.
7 - Security model: by default we export to * (all hosts) into a single
network - for isolated networks - in SG zones we need to play with
security groups & a global setting for dumb shared networks (without SG)
because of security implications - requires further discussion.
8 - We export with default, best practices NFS options - anything
against no_root_squash?
9 - Explore exporting the file share via multiple protocols - sftp,
tftp, smb, nfs, http(s)? - The issue here is authentication becomes a
problem, also user permissions will get messy and possibly conflict with
no_root_squash, in fact might require an all_squash and everything
mapped to a single user that will be then also used for all those other
services. Also logging will become necessary. Thoughts?
10 - UI details, but this will probably show up in the Storage section
somehow.
11 - Display free/used space, create alerts for full disk etc for this
appliance.
12 - Formatting and setting up to be done by an internal agent,
specifics are sent via the kernel cmd line of the VM, similar to how we
configure system VMs.
What do you folks think of these points and have I missed anything
crucial?
On 2024-06-04 05:04, Abhisar Sinha wrote:
Hi,
I would like to propose supporting storage filesystem as a first-class
feature in Cloudstack.
The File Share can be associated with one or more guest networks or vpc
tiers and can be used by any VM on the network in a shared manner. It
is designed to be resizable and highly available. This feature can
later be used as integration endpoints with the CSI driver, go-sdk,
Terraform, Ansible and others.
The draft functional spec is here :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Filesystem+as+a+First+Class+Feature
Looking forward to your comments and suggestions.
Thanks,
Abhisar
