[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] logsys in cluster3



On Mon, Jun 30, 2008 at 06:38:48PM +0200, Fabio M. Di Nitto wrote:
> On Mon, 30 Jun 2008, David Teigland wrote:
> 
> >- configuration setup: big blocks of setup code are repeated and largely
> > the same, make this less
> 
> I will take care of this bit since i already done it.
> 
> the api will look like:
> 
> int gimme_logging_config_data(char *name, int debug)
> 
> return 0 if ok 1 on failure
> char *name is the subsystem name as declared
> debug = 0 if no debug override is coming from cli or envvar, 1 if debug 
> has been forced by cli or envvar.
> 
> I still would like to agree on be able to try to config logging as early 
> as possible and then try later if it fails tho.
> 
> This problem would just disappear if we can agree on the other common 
> cluster connection bit. At that point, we configure once we connect and we 
> keep logging only the attempts to connect. Everybody is happy everafter ;)
> 
> > ccs should notify programs
> > of cluster.conf change,
> 
> cman will take care of this since ccs is just a plugin now and cman has 
> the API there and i see little gain to do it again. Ok?

OK, the details are still a little hazy for starting up a program.  When a
program starts up it needs to interact with cman, ccs and logsys, and all
three of those are somewhat interdependent.

- setup logsys nominally, so that the cman/ccs setup steps can do logging
  . if this fails, just go on

- connect to cman
  . if this fails, exit (hopefully the nominal logging above worked)

- wait for cman to be fully running
  . do we want everyone to put a finite loop around this?
  . if this fails, exit
  . keep the cman connection open as long as the program is running

- connect to ccs
  . could this fail even if cman is already ok above?  do we need a
    retry loop here?
  . keep the ccs connection open as long as the program is running

- read from ccs the optional cluster.conf logging settings
  . if this fails, just go on
  . reconfigure logsys, replacing the nominal config in step 1

- as the program runs, ccs/cman notifications may arrive indicating
  that cluster.conf has changed. when one of these callbacks arrives:
  . reread the logsys config and modify logging behavior accordingly
  . reread any other dynamic cluster.conf settings
  . (I assume I poll on the ccs connection fd which tells me when there's
     a change?)

Is there anything missing?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]