From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Mon, 30 Jun 2008 12:31:58 -0500 Subject: [Cluster-devel] logsys in cluster3 In-Reply-To: References: <20080630152301.GA31662@redhat.com> Message-ID: <20080630173158.GC31662@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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?