On Fri, 2009-09-04 at 13:55 +0200, Sylvain Jeaugey wrote:
> On Fri, 4 Sep 2009, Jeff Squyres wrote:
> > I haven't looked at the code deeply, so forgive me if I'm parsing this wrong:
> > is the code actually reading the file into one list and then moving the
> > values to another list? If so, that seems a little hackish. Can't it just
> > read directly to the target list?
> On the basic approach, I would have another suggestion, reducing parsing
> and maybe a bit less hackish : do not introduce another file but only a
> keyword indicating that further overriding is disabled ("fixed",
> "restricted", "read-only" ?).
> You would therefore write in your configuration file something like:
> notifier_threshold_severity=notice fixed
> or more generally :
> key=value flags
> Maybe we don't have a way to differenciate flags at the end with the
> current parser, so maybe a leading "!" or "%" or any other strong
> character would be simpler to implement while still ensuring
The current parser eats up all characters after the "=": everything that
is between the "=" and the eol is considered as the paramter's value.
So the second approach you're proposing seems better to me.
But if we do this, the extesension I proposed in my RFC will be harder
This new functionality can be extended in the future in the following
way: allow the administrator to specify boundaries within which an MCA
parameter is allowed to be changed by a higher priority setting. This
means that the administrator should declare min and max values (or even
a set of discrete values) for any such parameter. Then, any higher
priority setting will be done only if the new value belongs to the
But actually, may be that extension is not desirable at all. In that
case, I agree that your prposal is a very good compromise:
. single parser (though it should be enhanced)
. single configuration file
Nadia Derbey <Nadia.Derbey_at_[hidden]>