Bug 1612814 - [RFE] Allow users to change logrotate configuration in podified CloudForms
Summary: [RFE] Allow users to change logrotate configuration in podified CloudForms
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: cfme-openshift-app
Version: 5.9.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: GA
: 5.10.0
Assignee: Gregg Tanzillo
QA Contact: Ievgen Zapolskyi
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-06 10:50 UTC by Niladri Roy
Modified: 2022-03-13 15:21 UTC (History)
10 users (show)

Fixed In Version: 5.10.0.11
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-07 22:45:46 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0213 0 None None None 2019-02-07 22:45:50 UTC

Comment 4 Satoe Imaishi 2018-08-16 13:43:40 UTC
https://github.com/ManageIQ/manageiq-pods/pull/301

Comment 5 Nick Carboni 2018-08-23 15:29:18 UTC
Since the console isn't usable in the podified version of CF the config map added by David is the best solution to this issue.

I'll change the title to reflect the problem trying to be solved (ability to alter logrotate configuration in podified server) rather than a proposed solution to the problem (change appliance console).

Comment 6 David Luong 2018-08-23 22:30:52 UTC
Nick, you think we can utilize that part of the appliance console where we change the log configuration if we change the logrotate.conf within the pod itself and deploy the miq_logs.conf in the persistent folder where we store all other persistent data?

I can most likely write the logrotate.conf change and the persistent folder part, but I don't know how feasible it is to import that logrotate configuration function back into the pod version of CloudForms.

Let me know your thoughts.  The PR I wrote was just a quick fix due to urgency from the customer, but it is still a bit inelegant since if they want to change the logrotate for any reason they'd have to find where it is in the template and then destroy the cloudforms-0 pod just for that reason and have it restart again.

Comment 7 Nick Carboni 2018-08-24 13:08:27 UTC
No, I think the config map is actually the better way to do this here.

The persistent storage for server data was a bit of a hack to make the pod seem more like a regular appliance when we were doing the first pass at the pods project. I would prefer to move towards more openshift-native solutions whenever possible.

As for the customer struggle, if they want to change the logrotate config then they should edit it live in the project and the CF server pods will redeploy for the config change. I would suggest keeping their template up to date as well if they need to redeploy the whole project, but there's no need to do that just to change this one config map.

Comment 8 David Luong 2018-08-24 14:48:02 UTC
Crystal clear, thanks Nick!

Comment 9 Ievgen Zapolskyi 2018-10-16 11:39:03 UTC
Verified in 5.10.0.19

Comment 11 errata-xmlrpc 2019-02-07 22:45:46 UTC
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, 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/RHBA-2019:0213


Note You need to log in before you can comment on or make changes to this bug.