Bug 1728350
Summary: | seeing duplicated row entry when doing a report | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Peter Ruan <pruan> |
Component: | Metering Operator | Assignee: | tflannag |
Status: | CLOSED UPSTREAM | QA Contact: | Peter Ruan <pruan> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 4.2.0 | CC: | emoss, klamenzo, sd-operator-metering, wsun |
Target Milestone: | --- | ||
Target Release: | 4.4.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Known Issue | |
Doc Text: |
Cause:
There's a problem where Hive Metastore cannot drop a table in an s3 bucket path once a user has deleted a Report.
Consequence:
In the case where a user then re-creates that same deleted Report, the reporting data will still exist which results in duplicate row entries.
Workaround (if any):
You would need to manually delete this data yourself.
Result:
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-02-05 21:29:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Ruan
2019-07-09 18:34:15 UTC
I believe this is related to using s3 for storage and deleting the namespace to uninstall. Because our operator and pods run in the namespace where we instruct users to create reports, sometimes, metering may be unable to clean up resources outside the cluster before the pods are deleted. We have a few approaches we will need to investigate: - Running metering components/operators/pods in a namespace separate from where reporting resources are created. - Enabling finalizers by default. - Handling bucket deletion when we created the bucket. Enabling finalizers is a lot trickier than I'd hoped, and will likely require us to change how we deploy things (running them in a separate namespace), so I think that's off the table in the short term. Handling bucket deletion seems relatively easy but when I tested it seems like namespace deletion often prevents the operator from having time to do clean up. I'm wondering if documenting that the bucket needs to manually cleaned up is sufficient in the short term. Alternatively, we can also disable bucket creation so that users are always 100% in control of the bucket, making it more clear we will not do clean up. Longer term, I believe having bucket creation handled by something like the AWS service operator may make sense, and then creation/cleanup can be done by that operator instead of ours. Especially since the lifecycle of the bucket and metering may be different. I'm moving this to target 4.3 and we will cover this in our documentation for 4.2. Added more info to the docs here https://github.com/openshift/openshift-docs/pull/19498 |