http://bugzilla.opensuse.org/show_bug.cgi?id=917638
--- Comment #5 from Dejan Muhamedagic
In which circumstance is this necessary? Is it when hb_report is called by crmsh?
Yes. Something like adding "-l /var/log/pacemaker.log" or similar.
Is there a concrete situation where you needed this?
Sitting next to Lars who's trying to use history to look at the logs on a half broken installation :-)
I am trying to understand what the use case is so I can know if any suggestion I make would actually work. :)
Given that the thing is supposed to help debug the stack in all possible situations, we may need to hold its hand now and then. Note also that hawk may need this too. Does hawk invoke hb_report itself or through crmsh?
I don't like relying on environment variables, that seems fragile and requires being able to change the tool as well...
I also don't like the environment variables affecting runtime in such a way.
I think the crmsh configuration option might work, but at the same time I feel like it's uglier than is necessary..
Well, I'm not sure about it either.
The crmsh getopt choice I think is confusing.
Clumsy and then there's also a problem with quoting.
How about a special command under the history level? Something like
crm history report_options -l /var/log/pacemaker.log
That'd be cumbersome. Needs to be run every time and then you cannot use one-shot history commands. Related: the latest and greatest solution to the pacemaker logging problem, logging directly to /var/log/pacemaker.log, is not covered with hb_report. I suspect that the kludge won't survive for too long, but we probably need it, at least I noticed that Yan asks for that file every time.
To me the current hb_report format looks fine. Or would you want to change that?
Well, I put it in the far distant future because I am not sure it is worth the actual effort. I don't have any major reason to replace hb_report right now, but thinking ahead, it seems like a worthwhile goal at some point to have crmsh do that part.
Indeed. One practical issue currently is having hb_report effectively in two places. I think that they are already a bit out of sync (need to check that). Maybe we should at least plan for glue 1.0.13 to drop hb_report. Somehow, for that crmsh should probably install hb_report into /usr/sbin and conflict with cluster-glue<=1.0.12. I really don't like moving things around as it always introduces problems for somebody, but this time it seems inevitable. What are your thoughts on this?
For one thing, hb_report has its own way of figuring out what OCF_ROOT and other system constants like that should be, which may result in it using a different setting than crmsh. It would be better to have that all configured by crmsh in one place.
Yes, definitely. hb_report occasionally jumps through hoops to cover all possible pacemaker installations and directory locations. crmsh as well. -- You are receiving this mail because: You are on the CC list for the bug.