Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serviceability storage in S3 Object Buckets #171

Open
ron1 opened this issue May 29, 2020 · 2 comments
Open

Serviceability storage in S3 Object Buckets #171

ron1 opened this issue May 29, 2020 · 2 comments

Comments

@ron1
Copy link

ron1 commented May 29, 2020

Feature Request

The only shared storage in many environments is Object Buckets. Currently the Open Liberty Operator serviceability feature requires shared file storage, i.e., RWX PVCs, which are not available in these environments.

Support serviceability storage in Object Buckets by allowing users to configure a Service Binding to one of the following S3 Object Storage Backing Service Operators available on OperatorHub.io: awss3operator, cos-bucket-operator, lib-bucket-provisioner, minio-operator, noobaa, or rook-ceph.

@leochr
Copy link
Member

leochr commented May 29, 2020

@ron1 The serviceability PVC created automatically by the operator (based on the serviceability.size parameter) specifies access modes ReadWriteMany (to allow multiple pods to write to the same storage) as well as ReadWriteOnce. Alternatively, a custom PVC can also be specified using the serviceability.volumeClaimName parameter. https://github.com/OpenLiberty/open-liberty-operator/blob/master/doc/user-guide.adoc#storage-for-serviceability

We'll look into using storage configured by Service Binding for serviceability. Thank you.

@ron1
Copy link
Author

ron1 commented May 30, 2020

@leochr The following phrase in the documentation "The single storage will be shared by all Pods of an OpenLibertyApplication instance" gave me the impression that an RWX PV was required. If the operator is smart enough to use a RWO PV for each pod in the Deployment when no RWX PV is available, then maybe this Feature Request should be replaced with a simple Documentation change to clarify the above phrase? In this case, the Feature Request is probably overkill. WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants