Description of problem: Encrypted data cannot be compressed, and so wont give desired results on compression card in persistent dashboard. UI to add warning to make user aware about this while creating compressed pools. How reproducible: 2/2 Steps to Reproduce: 1. Navigate to Storage class view from left menu 2. Try creating RBD storage class 3. Create new Pool Actual results: No warning against compression checkbox. Expected results: Warning about effects of compression on data encryption and performance. Additional info:
@Yuval, as per this, we will need a warning message in pool creation modal when user enables compression, please suggest some message, and where in the modal we can keep it?
Perhaps "warning" is too strong of a word? Is "notice" sufficient? Is there a precedent? See related doc.
does it make sense to enable compression when encryption is on? if not, I would disable the compression checkbox if encryption is enabled
Hi, I am working on this issue. I need to clarify one small doubt, Do I need to disable compression when anyone or both (cluster-wide, storage-class-wide) encryption are enabled? I mean, This disabling compression checkbox condition is not associated with any particular encryption type, right?
I have discussed with James Espy about this issue, The issue is when the user tries to write any already encrypted data into a compressed pool would not successfully compress and performance may suffer (comment4 and comment 3 are misunderstandings). So we don't need to disable the compression option here. We need a clear warning message to indicate the user while choosing the compression option. James Espy's explanation: As I understood it, this BZ message was to be directed to users whose data was already encrypted, e.g. at the client, and hence un-compressible by Ceph. The message to the user would be that if they choose to enable compression when creating a pool, any already encrypted data they expected to write to this pool would not successfully compress and performance may suffer (compute resources would be used for nothing). I had understood that our encryption-at-rest function(s) would occur "after" our compression function and hence not be impacted. Also, James needs to extend this warning message to indicate that in general enabling compression could impact performance (well-compressed data means less storage space needed but at an added computational cost). @Yuval, please suggest some message, and where we can keep it?
Looking for suggestions as to properly wording this statement.
Suggested wording: "Before enabling compression for this pool, note that it may have little or no effect on already encrypted or otherwise randomized data. Also, enabling compression for any data may have an impact on performance." This would need to be run by doc folks for best wording. OK by Eran (separately for OCS 4.8 but same idea) and that it should be an "info" statement rather than a "warning."
I would suggest using it as an "Info" statement to inform users what happens when the user selects the checkbox to enable compression. Suggested wording: "Enabling compression may impact the performance of already encrypted or otherwise randomized data."
Elliott changed bug status from MODIFIED to ON_QA.
Since this is an alert, in this case, we can say --> "Enabling compression does not have any effect on encrypted or randomized data. Additionally, it can impact storage performance." WDYT?
another alternative --> Enabling compression for this pool will have little or no effect on encrypted or randomized data. Additionally, enabling compression for any data may have an impact on performance.
PR: https://github.com/openshift/console/pull/8066 The finalized message is: Enabling compression may result in little or no space savings for encrypted or random data. Also, enabling compression may have an impact on I/O performance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633