From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christine Caulfield Date: Thu, 24 Sep 2009 10:05:21 +0100 Subject: [Cluster-devel] [PATCH] STABLE3: enhance cman_tool to validate and distribute configuration files In-Reply-To: <1253724532.2727.12.camel@daitarn-fedora.int.fabbione.net> References: <4ABA3381.2020809@redhat.com> <1253724532.2727.12.camel@daitarn-fedora.int.fabbione.net> Message-ID: <4ABB3651.10005@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 23/09/09 17:48, Fabio M. Di Nitto wrote: > Hi Chrissie, > > On Wed, 2009-09-23 at 15:41 +0100, Christine Caulfield wrote: >> This patch adds significant functionality to 'cman_tool version'. If -r0 >> is specified, then the configuration file is validated (using >> ccs_config_validate), distributed around the cluster (if necessary, >> using ccs_sync) and activated. This provides a single command to update >> a configuration ... something people have been asking for for ages. > > wooooo > >> >> I'm not 100% happy about bundling it into cman_tool version, but neither >> am I convinced that this warrants another cman_tool sub-command ... so >> if anyone has any better ideas please speak up. > > No more subcommands.. I think this is enough. > > The patch looks good but I think we need to add a few more details here > and there... > > We agreed to have validation to work with 3 config options: off (-D), > warning and fail hard. So I think -D could just take an option to > none,warn,fail or something like that. I'm not sure how useful this is in this situation. Distributing and loading an invalid configuration is not a useful thing to do, surely? And if you really insist on it, then I'd rather make it a two stage process of "oh, you're telling me it's broken", then "but I know better so do it anyway". Then there is some manual intervention to check the configuration is right - maybe it's a schema error on our part. But in many cases a bad config either won't load at all, or will make a mess of your cluster - and once it's been copied around you might have lost your valid backup! > I'd like to see an option to disable sync too. Even if we have ccs_sync, > not everybody might be using conga/luci and can at least allow them to > do it gently. Agreed, I've added -S > I don't recall exactly why we needed to propagate COROSYNC_CONFIG_IFACE > from cman_tool invokation. I am sure there was a very good reason for > that. If so we might have to propagate also other COROSYNC_ envvars > including LDAP bits.. because they will need to be available to > ccs_config_validator and I'll also need to make the validator a bit less > picky about overriding the environment if the environment is already > loaded (this is my task of course). We need COROSYNC_CONFIG_IFACE so that the validation process knows what configuration system corosync actually used to load it's configuration from ... and where it will reload the new one from. You can't change this on the fly but you CAN edit config files to take effect next reboot. So we have to use the active system. I agree that LDAP needs other env variables but am not quite sure how to add them. Either we hard-code into cman_tool the variables we can use, or we copy all variables starting with COROSYNC_ into objdb and extract them again before validation! Chrissie