Op 20-11-2025 om 09:38 schreef Mohammad Hussein:
Hello CloudStack Team, Dell EMC ECS is a software-defined cloud storage platform that supports both object and file-system protocols, with a primary focus on object storage. It provides scalable, durable, and efficient storage capabilities for modern applications, and we have been using it in a production environment for three years. Based on the existing MinIO plugin, we have developed and fully tested an S3 object storage plugin for ECS within CloudStack, and we request your support in reviewing the code for this plugin. We also created a lab environment on Ubuntu by cloning the CloudStack source code from GitHub and setting up the development environment following the official installation guidelines: https://github.com/apache/cloudstack/blob/main/INSTALL.md . Unlike MinIO, which requires only an access key and a secret key when integrating object storage with CloudStack, the ECS implementation operates through the ECS management API exposed on each ECS node over port 4443. The ECS API URL points to this management API endpoint. In our deployment, the API is placed behind HAProxy and exposed externally on port 443 to provide secure access. The service account username and password correspond to the ECS management user that CloudStack uses to create buckets, manage object users, and perform related operations. To create this account, log in to the ECS administrative console and navigate to Manage → Users → Management Users, then create a new user with System Admin privileges. A dedicated namespace must also be created within ECS to contain the buckets that CloudStack provisions. This namespace must be provided when configuring ECS as an object storage provider in CloudStack. Using different namespaces enables multiple CloudStack object storage backends to operate on the same ECS cluster while maintaining isolation. The ECS Public and Private URL fields define the endpoint that provides the S3-compatible object storage interface. ECS nodes expose this service on port 9020 for non-TLS access and 9021 for TLS-secured access. In our deployment, this service is also routed through HAProxy and exposed externally on port 443, offering a secured S3 endpoint.The Public URL is shown to CloudStack users when viewing bucket details, while the Private URL is used internally by CloudStack when connecting to the ECS object storage service. Both values may point to the same endpoint, The Allow Insecure HTTPS option determines whether CloudStack accepts untrusted or invalid TLS certificates when communicating with the ECS management API. When disabled, CloudStack requires a valid and trusted certificate chain for all API interactions. Once the ECS object storage configuration has been completed, CloudStack users can begin creating buckets on ECS. When a bucket is created, CloudStack first provisions an object user in Dell ECS that corresponds to the CloudStack user initiating the operation. This object user is created using the CloudStack user’s unique identifier, for example: cs-0241420d-c2da-11f0-b425-0050569cb305 Here, the cs prefix designates that the account originates from CloudStack, followed by the internal CloudStack user UUID. During this initial creation process, ECS generates an access key and secret key for the newly created object user. The access key is identical to the ECS object user name, and the secret key is securely stored in CloudStack and displayed in the CloudStack UI as the Secret Key when viewing the bucket details. This credential-generation process occurs only once, at the time the CloudStack user creates their first bucket. For all subsequent bucket creations, CloudStack automatically reuses the existing ECS object user and its associated access/secret key pair. This mechanism ensures that each CloudStack user receives a unique and persistent set of S3 credentials, and that ECS maintains a strict one-to-one mapping between CloudStack users and ECS object users. When creating a bucket through CloudStack, several ECS bucket features can be configured. These features generally align with those available for MinIO but differ in behavior due to architectural and API differences between the platforms. Encryption: ECS supports bucket-level encryption however, it can only be enabled at the time of bucket creation. Once enabled, ECS does not allow encryption to be disabled. To reflect this limitation, the update-bucket view in CloudStack hides the encryption toggle, preventing users from attempting to modify an immutable setting. Bucket Policy: CloudStack supports setting ECS bucket policies with the same options provided for MinIO. Buckets can be configured as Private or Public, with CloudStack applying the appropriate access control settings through ECS. Versioning: Dell ECS fully supports bucket versioning. This feature can be enabled or disabled from CloudStack as needed. Unlike most ECS operations performed using the ECS management API versioning changes are executed through ECS’s S3 interface using the S3 endpoint URL. This matches ECS’s design, where versioning is controlled via the S3 protocol rather than the management API. Object Lock: Object Lock functionality was not implemented in this development iteration. CloudStack now prevents the use of Object Lock by design the option is removed from the UI for buckets created from ECS Object Storage, and any attempt to invoke this functionality through the API results in a clear error response indicating that Object Lock is not supported for ECS. Additionally, the Object Lock option is hidden in the Create Bucket UI to prevent users from selecting a feature that requires additional ECS parameters such as retention mode and retention period that were not implemented. This functionality may be added in a future enhancement. In the Update Bucket view, CloudStack provides the same modification capabilities for ECS buckets as it does for MinIO, with the exception of encryption settings. Users can update the quota, enable or disable versioning, and modify the bucket policy between Private and Public. The Encryption option is intentionally hidden, as explained earlier in the bucket-creation section: ECS does not permit changing the encryption state once a bucket has been created. CloudStack’s S3 Browser functions identically for ECS as it does for MinIO. All core operations such as uploading objects, downloading objects, and deleting objects are fully supported and executed through the ECS S3 endpoint. Users can navigate bucket contents, perform prefix-based searches, and manage objects directly through the CloudStack UI. As with MinIO, Dell ECS does not allow deletion of a bucket that contains objects or object versions. Attempting to delete a non-empty bucket results in an error message returned from ECS, indicating that the bucket must be emptied (including all object versions, if versioning is enabled) before deletion can proceed. This behavior is enforced by ECS and surfaced transparently through CloudStack. Lastly, we kindly request that you review the implementation in our CloudStack fork and provide feedback on any areas that may require optimization or improvement. We welcome any questions, comments, or indications of missing functionality. The fork is available at: https://github.com/mhkadhum/cloudstack
Thank you for the work! Extra plugins and support are always welcome. Could you open a Pull Request on Github? This makes it easier to review. Wido
Your feedback is greatly appreciated, and we look forward to preparing a pull request once we have incorporated your recommendations. Thank you for your time and support. Best regards.
