-
Notifications
You must be signed in to change notification settings - Fork 69
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
CredHub accumulates orphaned data in the the encrypted_value
table
#231
Comments
@dueckminor Thanks, we have this on our roadmap. |
#190 seems similar. |
I would like to give @dueckminor the medal🥇of the best Github issue I have ever seen. Very well documented, explained, with reproduction steps, and even a possible cleanup script. Sorry it took us so long to look at it. |
Fixed in CredHub 2.12.67. Thank you. |
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
Reopening this issue as we are undoing the fix that included database trigger creation in next release, because of the issue with Amazon RDS for MySQL where the trigger creation privilege is not part of default configuration and requires operator intervention and db restart. We will try to come up with resolution that does not involve database triggers. |
…y deletion - Re-implemented the fix for #231 with JPA cascade-remove instead of database triggers. - Modified the transaction propagation behavior of the unit test methods that verify `encrypted_value record` count, so the count can be obtained after the delete transactions is done. - Fixed typos in test code. [#187367323]
…y deletion - Re-implemented the fix for #231 with JPA cascade-remove instead of database triggers. - Modified the transaction propagation behavior of the unit test methods that verify `encrypted_value record` count, so the count can be obtained after the delete transactions is done. - Fixed typos in test code. [#187367323]
- Fixed #231 in JPA layer instead of using database triggers. - Used `LAZY` fetch for the JPA one-to-many mapping from `credential` to `crdential_version` because `EAGER` causes memory and perfromance issue when many credentials are loaded, e.g. `DefaultCertificatesHandler.handleGetAllRequest()`. The issue with `EAGER` fetch was reproducible in `DefaultCertificatesHandlerIntegrationTest`. - Made `DefaultCertificatesHandlerIntegrationTest` transactional so as not to commit test data. This not only makes sure no dirty test data is left but also makes the test runs a little faster. - Changed the `credetial_version.type` of test data in `DefaultCertificatesHandlerIntegrationTest` to a valid value 'cert' as previous invalid type value caused data vdalidation failure by Hibernate. - Changed properties of `CredentialVersionData` entity to be non-final, i.e. added Kotlin `open` keyword to them, so the lazy loading can work properly. This takes care of following exception for example: ``` WARN org.hibernate.tuple.entity.PojoEntityTuplizer - HHH000305: Could not create proxy factory for:org.cloudfoundry.credhub.entity.CredentialVersionData org.hibernate.HibernateException: Getter methods of lazy classes cannot be final: org.cloudfoundry.credhub.entity.CredentialVersionData#getUuid ``` [#187367323]
- Fixed #231 in JPA layer instead of using database triggers. - Used `LAZY` fetch for the JPA one-to-many mapping from `credential` to `crdential_version` because `EAGER` causes memory and perfromance issue when many credentials are loaded, e.g. `DefaultCertificatesHandler.handleGetAllRequest()`. The issue with `EAGER` fetch was reproducible in `DefaultCertificatesHandlerIntegrationTest`. - Made `DefaultCertificatesHandlerIntegrationTest` transactional so as not to commit test data. This not only makes sure no dirty test data is left but also makes the test runs a little faster. - Changed the `credetial_version.type` of test data in `DefaultCertificatesHandlerIntegrationTest` to a valid value 'cert' as previous invalid type value caused data vdalidation failure by Hibernate. - Changed properties of `CredentialVersionData` entity to be non-final, i.e. added Kotlin `open` keyword to them, so the lazy loading can work properly. This takes care of following exception for example: ``` WARN org.hibernate.tuple.entity.PojoEntityTuplizer - HHH000305: Could not create proxy factory for:org.cloudfoundry.credhub.entity.CredentialVersionData org.hibernate.HibernateException: Getter methods of lazy classes cannot be final: org.cloudfoundry.credhub.entity.CredentialVersionData#getUuid ``` [#187367323]
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
Re-opening as we still have to release the fix. |
Closing as fix is released: https://github.com/pivotal/credhub-release/releases/tag/2.12.70 |
What version of the credhub server you are using?
2.11.1
What version of the credhub cli you are using?
2.9.0
If you were attempting to accomplish a task, what was it you were attempting to do?
We rotate credentials regularly, and have seen that the size of the CredHub DB is growing constantly. The DB size is growing even if we rotate a credential by deleting and setting it (this deletes old credential versions).
What did you expect to happen?
I would expect, that the credhub database doesn't grow so fast. We had databases using 15 GB storage. After I have manually deleted the orphaned entries the database size was only 40 MB.
What was the actual behaviour?
Values it the
encrypted_value
table are worthless if there are no entries in thecredential_version
,password_credential
oruser_credential
table, because nobody can know to which credential the encrypted value belongs to.If I generate a password credential like this:
I get two additional entries in the
encrypted_value
table. One for the value and one for the parameters. But If I delete the credential, no values will be deleted from theencrypted_value
table.To get rid of these entries, you may use the following SQL query (use at your own risk!):
But if the database has already a huge size, this will take some time (It took about a week to delete all orphaned entries)
By adding some indexes you could speed it up dramatically:
But that is just to get rid of existing entries. I would expect that the encrypted values get deleted together with the corresponding entries in the other tables.
Please confirm where necessary:
If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)
The text was updated successfully, but these errors were encountered: