Hello Wido, https://github.com/apache/cloudstack/pull/12124
On Mon, Nov 24, 2025 at 12:59 PM Wido den Hollander <[email protected]> wrote: > > > 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. > > > >
