[Pacemaker] Stonith setup hostname params

Dejan Muhamedagic dejanmm at fastmail.fm
Fri Apr 1 15:34:07 CEST 2011


On Fri, Apr 01, 2011 at 11:05:29AM +0200, Andrew Beekhof wrote:
> On Fri, Apr 1, 2011 at 10:45 AM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> > On Fri, Apr 01, 2011 at 09:41:26AM +0200, Andrew Beekhof wrote:
> >> On Tue, Mar 29, 2011 at 3:28 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> >> > On Mon, Mar 28, 2011 at 09:08:32PM +0400, Pavel Levshin wrote:
> >> >> 28.03.2011 18:35, Dejan Muhamedagic:
> >> >>>> Currently, crm shell cannot handle quoted parameters with spaces from the command line. Try to enter it interactively:
> >> >>> The crm shell gets what bash (or dash) passes. The quotes are
> >> >>> gobbled by bash in that process. Basically, what you type is not
> >> >>> what crm sees.
> >> >>>
> >> >>
> >> >> I understand the mechanics. It is machine-centric and confusing to some
> >> >> users.
> >> >>
> >> >> It is not absolutely impossible to accept quoted parameters from command
> >> >> line. Quotes are stripped, but these parameters are preserved in single
> >> >> arguments.
> >> >>
> >> >>> Right. I really don't understand why's everybody trying to
> >> >>> configure the cluster directly from bash instead of doing it in
> >> >>> crm configure.
> >> >>>
> >> >>
> >> >> CRM shell offers this opportunity, that's why many users try to use it.
> >> >
> >> > The fact that the shell has this feature doesn't mean that it
> >> > should be misused. It was meant mainly for one-off management
> >> > commands (such as "resource stop" or "node standby") and only
> >> > very seldom for one-off configuration commands. There's a
> >> > plethora of things which can go wrong when used for
> >> > configuration directly from the command line. It also makes the
> >> > cluster work harder because every invocation has an implicit
> >> > commit and the changes immediately take effect.
> >>
> >> There are, as CTS shows, ways around that.
> >
> > You mean using CIB_file? Yes, that's one possibility, though I'm
> > not sure how many people know about it. Another would be to do
> > the changes in a shadow CIB.
> >
> >> > Because of that
> >> > the user also must pay attention to the order of configuration
> >> > elements which otherwise isn't necessary.
> >>
> >> Can you define constraints for resource's you've not defined yet?
> >> What about clone or group resource's that are also not yet defined?
> >>
> >> (If yes to either, that sounds more like a bug than a feature)
> >
> > What I meant is this: If you stuff all the configuration into a
> > file and do "configure load" or just feed it to "crm configure",
> > the order of elements in the file does not matter as long as all
> > referenced elements are presents at the commit time.
> >
> >> > It's a bit like taking
> >> > apples one by one from your garden into the house, instead of
> >> > bringing over a box of apples. Just worse than that. I could go
> >> > on, btw.
> >>
> >> I'm sorry, but this is all a pretty weak argument.
> >> Not that I consider proper quote escaping the crm shell's problem, but
> >> the ability to script the creation of a config is quite important.
> >
> > The proper way to script a configuration would be by way of
> > here-document or similar.
> >
> >> What about adding some additional sanity checking for the params section?
> >> It should be pretty easy to spot (and warn about) entries not of the
> >> form "name=value" which would be indicative of a quoting error.
> >
> > Unfortunately, CIB allows a parameter to be defined but not have
> > a value, that's why a token by itself within parameters is
> > considered to be this case.
> 
> True, but almost no-one uses that intentionally - thats more of a node
> attribute feature.
> If you see $name by itself and there is no $name parameter advertised
> in the metadata - its highly likely that there's a quoting issue.

True, that's most likely.

> You could require the syntax for that to be name= instead of just name though.

That could be a good idea. Though it's sure to look ugly.

> But anyway, thats why I suggested producing a warning rather than
> always trying to fix it.

Not sure how is it going to fit, it's certainly worth looking
at, but not very high priority.

Thanks,

Dejan

> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker



More information about the Pacemaker mailing list