From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] logsys in cluster3
Date: Mon, 30 Jun 2008 12:31:58 -0500 [thread overview]
Message-ID: <20080630173158.GC31662@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0806301731230.27368@trider-g7>
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?
next prev parent reply other threads:[~2008-06-30 17:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 15:23 [Cluster-devel] logsys in cluster3 David Teigland
2008-06-30 16:38 ` Fabio M. Di Nitto
2008-06-30 17:31 ` David Teigland [this message]
2008-07-01 5:01 ` Fabio M. Di Nitto
2008-07-01 16:37 ` David Teigland
2008-07-01 17:21 ` David Teigland
2008-07-01 19:12 ` David Teigland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080630173158.GC31662@redhat.com \
--to=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).