Hi Hideo-san, On Wed, Dec 16, 2009 at 11:20:44AM +0900, [email protected] wrote: > Hi Dejan, > > All right. > > >but I'll do something about it. We can track the > > issue in bugzilla 1972. > > Are you to revise it by a policy like lrmd?
Well, didn't feel like doing it now, but that may be necessary. I've already got a patch, but then anything a plugin spits on the stdin (when doing power requests and status) goes to log at the info level and there's no way around it. For instance, that makes it impossible for plugins to log at the debug level. I think we should revisit the whole external plugins logging and simply make them log directly through ha_log. Cheers, Dejan > If I can assist your work, please mail to me. > > Best Regards, > Hideo Yamauchi. > > --- Dejan Muhamedagic <[email protected]> wrote: > > > Hi Hideo-san, > > > > On Tue, Dec 15, 2009 at 09:33:08AM +0900, [email protected] wrote: > > > Hi Dejan, > > > > > > > The change is not difficult, but then we would need to change all > > > > external plugins too. It should've been done so in the first place. > > > > > > I understood it. > > > Will you adopt this patch till it is changed for processing same as lrmd? > > > > > > I attach a new patch. > > > > Thanks for the patch. It's still not clear to me what was your > > intention in the last part of the patch, which I quoted in the > > first reply, but I'll do something about it. We can track the > > issue in bugzilla 1972. > > > > Cheers, > > > > Dejan > > > > > Best Regards, > > > Hideo Yamauchi. > > > > > > > > > --- Dejan Muhamedagic <[email protected]> wrote: > > > > > > > Hi Hideo-san, > > > > > > > > On Mon, Dec 14, 2009 at 09:46:33AM +0900, [email protected] > > > > wrote: > > > > > Hi Dejan, > > > > > > > > > > > It would also be good to rename "isbufferd" to say "data_call". > > > > > OK. > > > > > > > > > > > That way we state that what is expected from the plugin is data > > > > > > on stdin (getinfo, get_confignames, hostlist). With the other > > > > > > calls (status and reset_req) we expect informational or error > > > > > > messages. > > > > > I think it to change it to structure such as lrmd without using popen. > > > > > (lrmd : fork + exec + pipe(stdout,stdin)) > > > > > > > > > > Is it a difficult change to make same as lrmd? > > > > > > > > The change is not difficult, but then we would need to change all > > > > external plugins too. It should've been done so in the first place. > > > > > > > > Thanks, > > > > > > > > Dejan > > > > > > > > > Best Regards, > > > > > Hideo Ymamauchi. > > > > > > > > > > --- Dejan Muhamedagic <[email protected]> wrote: > > > > > > > > > > > Hi Hideo-san, > > > > > > > > > > > > On Fri, Dec 11, 2009 at 09:50:13AM +0900, > > > > > > [email protected] wrote: > > > > > > > Hi Dejan, > > > > > > > > > > > > > > Sorry.... > > > > > > > Meanings of your comment cannot understand it well. > > > > > > > Please teach contents of the comment a little more intelligibly. > > > > > > > > > > > > Please ignore what I wrote. external_run_cmd uses popen() and the > > > > > > plugins use stdout for informational messages too. Not the best > > > > > > way, but we can live with that. > > > > > > > > > > > > I get the meaning of your patch, but still don't understand the > > > > > > part I quoted in the first reply. > > > > > > > > > > > > It would also be good to rename "isbufferd" to say "data_call". > > > > > > That way we state that what is expected from the plugin is data > > > > > > on stdin (getinfo, get_confignames, hostlist). With the other > > > > > > calls (status and reset_req) we expect informational or error > > > > > > messages. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Dejan > > > > > > > > > > > > > Best Regards, > > > > > > > Hideo Yamauchi. > > > > > > > > > > > > > > --- Dejan Muhamedagic <[email protected]> wrote: > > > > > > > > > > > > > > > Hi Hideo-san, > > > > > > > > > > > > > > > > On Thu, Dec 10, 2009 at 05:34:56PM +0900, > > > > > > > > [email protected] wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > We are troubled with log in reset of stonith. > > > > > > > > > > > > > > > > > > Log is not output till practice is completed in the reset > > > > > > > > > movement of stonith. > > > > > > > > > > > > > > > > I see your point. > > > > > > > > > > > > > > > > > The stonith module which is extenal which we made gives log > > > > > > > > > during reset movement > > and > > > > > > chases > > > > > > > > movement. > > > > > > > > > For us, the chase of the reset movement is very useful. > > > > > > > > > > > > > > > > > > We think that the whole reset movement should be over the log > > > > > > > > > at any time. > > > > > > > > > > > > > > > > The stdout/stderr should be split with stderr going immediately > > > > > > > > to the log and the content of stdout returned to the caller. Any > > > > > > > > chance to implement it that way. > > > > > > > > > > > > > > > > > I created a patch for external.c. > > > > > > > > > Please teach it if there is the revision method that, > > > > > > > > > besides, is good. > > > > > > > > > > > > > > > > After taking a quick look, I find this part a bit strange: > > > > > > > > > > > > > > > > + if (fgets(buff, BUFF_LEN, file)) { > > > > > > > > + LOG(PIL_INFO, "%s: '%s' output: > > > > > > > > %s", __FUNCTION__, cmd, buff); > > > > > > > > + if (Debug && data) { > > > > > > > > + LOG(PIL_DEBUG, "%s: > > > > > > > > '%s' output: %s", __FUNCTION__, cmd, buff); > > > > > > > > + } > > > > > > > > + tosleep = FALSE; > > > > > > > > + } > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Dejan > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > Hideo Yamauchi. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________________ > > > > > > > > > Linux-HA-Dev: [email protected] > > > > > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > > > > > Home Page: http://linux-ha.org/ > > > > > > > > > > > > > > > > _______________________________________________________ > > > > > > > > Linux-HA-Dev: [email protected] > > > > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > > > > Home Page: http://linux-ha.org/ > > > > > > > > > > > > > > > > > > > > > > _______________________________________________________ > > > > > > > Linux-HA-Dev: [email protected] > > > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > > > Home Page: http://linux-ha.org/ > > > > > > _______________________________________________________ > > > > > > Linux-HA-Dev: [email protected] > > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > > Home Page: http://linux-ha.org/ > > > > > > > > > > > > > > > > _______________________________________________________ > > > > > Linux-HA-Dev: [email protected] > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > Home Page: http://linux-ha.org/ > > > > _______________________________________________________ > > > > Linux-HA-Dev: [email protected] > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > Home Page: http://linux-ha.org/ > > > > > > > > > > > _______________________________________________________ > > > Linux-HA-Dev: [email protected] > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > Home Page: http://linux-ha.org/ > > > > _______________________________________________________ > > Linux-HA-Dev: [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > Home Page: http://linux-ha.org/ > > > > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
