http://bugzilla.opensuse.org/show_bug.cgi?id=917638 --- Comment #1 from Kristoffer Gronlund --- I don't like any of these options :D In which circumstance is this necessary? Is it when hb_report is called by crmsh? For crm_report, crmsh actually never calls it. I only added the ability to open reports generated by crm_report. So there is no need for this kind of feature to adapt to that tool. (for the far distant future, my personal dream ;) is to have crmsh capable of collecting all of the history data on its own without external dependencies. Of course it should still be able to open reports generated by other tools). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=917638 --- Comment #3 from Kristoffer Gronlund ---

...

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? I am trying to understand what the use case is so I can know if any suggestion I make would actually work. :) I don't like relying on environment variables, that seems fragile and requires being able to change the tool as well... I think the crmsh configuration option might work, but at the same time I feel like it's uglier than is necessary.. The crmsh getopt choice I think is confusing. How about a special command under the history level? Something like crm history report_options -l /var/log/pacemaker.log ...

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. 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=917638 --- Comment #5 from Dejan Muhamedagic --- (In reply to Kristoffer Gronlund from comment #3)

...

...

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.

http://bugzilla.opensuse.org/show_bug.cgi?id=917638 --- Comment #7 from Dejan Muhamedagic --- (In reply to Kristoffer Gronlund from comment #6)

Okay, great :) I think I understand what the issue is, and I also think we agree in not really being overly fond of any of the ideas we have for solving it so far. It sounds like adding a crmsh configuration option is the least bad choice we've got at this point?

Probably. At least it seems to be the one least in the way :)

So, one thing is that hb_report now has a list of places where it looks for log files. Maybe this list should be configurable in some way? That seems like it might solve this problem at least.

hb_report assumes that log files are created by syslog and can only find such logs. Instead of implementing some heuristics, I just logged a unique line at the given facility and then look for it. Unfortunately, with the advent of syslogd, that doesn't always work, as the log messages get delayed :-/ If you think that you can improve matters in this area that'd be great.

Also yes, we need to add /var/log/pacemaker.log to the list by default..

Not only that. We'd also need to show it in crmsh history by default instead of those found through syslog. One of the side effects is that lines with severity>=notice are going to be duplicated, so merging pacemaker.log and syslog logs is not an option.

I also agree that having hb_report in two places is bad. The plan for moving it completely into crmsh looks good to me, but those kinds of changes are always hairy..

Yes. It's one of those things that one keeps postponing ;-)

I have the same problem with moving the hawk templates into a shared package between crmsh and hawk to unify the templates there. They will need to be upgraded together. but I guess it is inevitable too.

Yep, most probably. -- You are receiving this mail because: You are on the CC list for the bug.