To fully configure MinIO from a given CRD - cniackz/public GitHub Wiki
Objective:
To be able to configure MinIO features from a given CRD
Subnet discussion:
Diagram:
Original Idea:
IMO I think it makes sense to run some sidecar style container or a mc-job to pull the mc container to create buckets instead of initializing minioClient internally in operator. Operator perhaps can avoid having S3 access to perform data operations as this can expose many strange things. Using mc as the container makes it simple just like the helm chart behavior and it can be controlled through the tenant namespace.
Reasoning:
I believe this is a powerful idea because it allows us to configure MinIO effectively using 'mc' even from a Custom Resource Definition (CRD). This feature will be incredibly helpful for DevOps in automating MinIO management. Additionally, it enables us to establish a direct 'mc' connection, thereby reducing the complications associated with intermediate solutions where the interaction between different layers can make debugging and maintenance challenging.
Advantages:
- We debug single
mccommand rather than multiple spots.
Declarative:
We aim to follow a declarative approach when handling tasks. Instead of granting direct access to MinIO commands from Custom Resource Definitions (CRD), we prefer specifying the desired state within the CRD. This approach allows us to introduce small features as needed by our customers.
In this illustrative example, I demonstrate how to fully enable LDAP by enabling end users to attach a policy to a user. Currently, achieving this requires manual use of the 'mc' command in an imperative manner.