[Pacemaker] Managing resources - classes

[Dejan Muhamedagic]

On Fri, May 29, 2009 at 10:13:35AM +0200, Andrew Beekhof wrote:
> On Thu, May 28, 2009 at 7:33 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> > Hi,
> >
> > On Thu, May 28, 2009 at 03:59:49PM +0200, Andrew Beekhof wrote:
> >> On Wed, May 27, 2009 at 4:22 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> >> > Hi,
> >> >
> >> > On Wed, May 27, 2009 at 08:42:06AM -0400, Eliot Gable wrote:
> >> >> http://clusterlabs.org/wiki/Documentation
> >> >>
> >> >>
> >> >> First, read this (probably ten times or so, since it won???t make complete sense and you will miss various details the first couple of times):
> >> >>
> >> >> http://clusterlabs.org/mediawiki/images/f/fb/Configuration_Explained.pdf
> >> >>
> >> >> Then, if you want to use the CLI, read this:
> >> >>
> >> >> http://clusterlabs.org/mediawiki/images/8/8d/Crm_cli.pdf
> >> >>
> >> >> Or check out any other links on that main documentation site.
> >> >>
> >> >> I strongly recommend you start out learning with the XML CIB
> >> >> and then, if you want, move to the CLI. Everything makes much
> >> >> more sense if you understand the XML stuff.
> >> >
> >> > I'll disagree here. The crm shell is there to let the vast
> >> > majority of people start working with Pacemaker without having to
> >> > read XML. And then also enable most of them never to think about
> >> > XML. crm should be able to represent all cluster configurations
> >> > without the XML scaffolding (and you won't miss much, it is
> >> > horrible anyway).
> >>
> >> oi! :-)
> >> its much better than it was in 0.6

BTW, don't get me wrong, I'm not complaining about the CIB
design, but about the XML's general properties :)

> >> > In short, what would one gain by reading XML
> >> > instead of the stripped crm representation?
> >> >
> >>
> >> Without question the crm shell is the best tool for changing the configuration.
> >>
> >> I still find the stripped representation harder to read though - I
> >> seem to have trouble finding and focusing on the bits i'm interested
> >> in at the time. ?But I've been starring at the full form for over 5
> >> years now, so that may not be surprising :-)
> >
> > So, which part do you miss? :) Seriously, perhaps formatting
> > could be improved or something. I'm always listening. And,
> > frankly, I don't like the crm representation that much either,
> > but couldn't think of any better way at the time. Still, what it
> > makes it great for me is that I don't have to stare like a sheep
> > at XML, it always gives me headache.
> 
> I was thinking about this some more... I think I finally figured out
> the problem and possibly what to do about it.
> (Although I just checked the latest crm output, and it looks like
> you've already made some nice improvements).
> 
> The XML is usually read in "formatted" form, in that its indented.
> The indenting helps to group elements so that one can focus on just
> what is currently interesting - just the params, or ops, or whatever.
> 
> What I think is missing from the syntax is visual differentiation of
> the shell's keywords (op, params, location, etc..).
> Originally I thought of using color or a bold font (like most prompts
> use), but that requires special characters and every shell does it
> differently.  So ultimately that seems to cause more problems than it
> solves.

It could be a user preference setting or a command line option.
This is not a bad idea. Though it would break reusing the output
(i.e. parsing it again). So, perhaps a command line option is
better.

> How about displaying the keywords in ALLCAPS though?
> Something like:
> 
> PRIMITIVE FencingChild stonith:external/ssh \
> 	PARAMS hostlist="c001n01 c001n02 c001n03 c001n04 c001n05 c001n06
> c001n07 c001n08" livedangerously="yes" \
> 	OP monitor interval="120s" timeout="300" \
> 	OP start interval="0" timeout="180s" \
> 	OP stop interval="0" timeout="180s"
> 
> It wasn't bad to begin with, but it feels nicer now and is more
> readable when it appears as a single line (which I also come across).
> 
> PRIMITIVE FencingChild stonith:external/ssh PARAMS hostlist="c001n01
> ... c001n08" livedangerously="yes" OP monitor interval="120s"
> timeout="300" OP start interval="0" timeout="180s" OP stop
> interval="0" timeout="180s"
> 
> Thoughts?

Yes, this looks like an improvement too. Once in a while I'd come
across a really huge configuration and indeed it was rather
unreadable. Though people shouldn't really be making such big
setups anyway ;-)

> Would that be hard to implement?

No, I don't think so.

> On the parsing side, I guess it would "just" be a matter of doing the
> python equivalent of strcasecmp().

Yes. I think that there's already a basic filtering utility, but
still unused.

Another option would be to implement an alternative parser.
Something like named.conf (C like). That one looks more pleasing
to me, but I may be biased ;-)

Thanks,

Dejan