Issue: fluentd does not have enough time to parse all logs before container is garbage collected. Suggestion: In container garbage collection, there is a parameter minimum-container-ttl-duration which is calculated from container create time. Looking for a way to configure it to calculate from container died time so flunetd will have enough time to parse all logs before the container and its log got deleted by garbage collection. for example, if we set minimum-container-ttl-duration at 10 minutes. 1. pod starts at time 0, got deleted at 5m, it should be deleted at 15m but it got deleted at 10m 2. pod starts at time 0, got deleted at 1h, it is expected to be deleted at 1h10m but it will got deleted almost immediately
1. Proposed title of this feature request fluentd log parsing prior to container GC 3. What is the nature and description of the request? Allow time for fluentd to parse logs before container is GC'd. 4. Why does the customer need this? (List the business requirements here) After the fact review of logs 5. How would the customer like to achieve this? (List the functional requirements here) Customer Suggestion: In container garbage collection, there is a parameter minimum-container-ttl-duration which is calculated from container create time. Looking for a way to configure it to calculate from container died time so flunetd will have enough time to parse all logs before the container and its log got deleted by garbage collection. for example, if we set minimum-container-ttl-duration at 10 minutes. 1. pod starts at time 0, got deleted at 5m, it should be deleted at 15m but it got deleted at 10m 2. pod starts at time 0, got deleted at 1h, it is expected to be deleted at 1h10m but it will got deleted almost immediately 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? One not found. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? Not provided 9. Is the sales team involved in this request and do they have any additional input? Not provided. 10. List any affected packages or components. fluentd 11. Would the customer be able to assist in testing this functionality if implemented? TBD
With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant. This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.