Re: [Condor-devel] RFC: an implementation of classads enhanced with macro evaluation

[Erik Erlandson <eje@xxxxxxxxxx>]

On Tue, 2012-03-13 at 15:45 -0500, Alan De Smet wrote:
> Erik Erlandson <eje@xxxxxxxxxx> wrote:
> > An interesting use case for this extension is that it would allow a
> > system to be configured using classads.  For example, in theory condor
> > could be configured using the same classad system that it already uses
> > for all its other data.
> 
> I like the idea of ClassAds as configuration.  However, there has
> been resistance to major changes to the configuration system,
> resistance that lead to the most recent overhaul being far scaled
> down from the original design.  A complete replacement with a
> ClassAd based system would be an even bigger step.  

It would be a disruptive change.  It's one of those things that is the
"right thing" to do until you factor in the disruption of the software
and backward compatability, and then it's arguably not.

I decided it was worth demonstrating so that the community is aware that
a clean language solution exists, if a sufficient motivation ever
presents itself to undertake reworking the code.  Or, in case anybody
ever has an interest in other software  projects that could use classads
for internal data representation and configuration.

>   Without a strong use
> case like configuration, the functionality seems like unnecessary
> complexity.

As classads are currently used within condor, I can't think of much use
case for macro expansion.  Unless it was for supporting classad submit
files, and then you'd probably want to use something besides '$' since
that's already taken.  Obviously, any distinguishing symbol could be
used.

As far as complexity goes, one of the things I was sort of excited by is
that providing macros turns out to be not really complex at all.  You
add a bit of machinery for maintaining currently-parsed variable
context, and whenever you parse a subexpression inside of $(), you call
your already-implemented eval_expression function, with the current
variable context, and pass that up the parse.

There simply aren't lots of additional moving parts required, that would
add significant complexity or lots of new fail points.


> 
> I think you're proposing rewriting the ClassAd library from
> scratch and adding a new dependency (ANTLR).  Is there a reason
> it's not possible or appropriate to add this functionality to the
> existing, well tested library?  Or did I misunderstand?

There's no reason you couldn't add macro expansion to the current
implementation.  The implementation details would be different, owing to
how condor's classad semantic differs from the spec, and how its code is
factored, etc.

Any parse-generation tool that supports customizable code for building
abstract syntax trees / internal representations (which I think is all
of them), would support the tweaks enabling macro expansion.

Unless you had plans for doing configuration (or submission) with
classads, I don't currently see a use case for it.

I admit to having some geeky plans for writing a spec-compliant
implementation of classads for C++, in my copious spare time.

Again, dropping such a thing into condor itself would also incur
disruption trade-offs, but if/when I completed such a thing, at least
that would make available as an option, or for other software projects,
etc.