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

[Alain Roy <roy@xxxxxxxxxxx>]

On Mar 11, 2012, at 2:37 PM, Erik Erlandson wrote:
> I have been fooling around with an implementation of the ClassAd 2.4
> language spec, and I came up with a surprisingly clean extension to the
> language that provides macro evaluation at parse time, with the full
> ClassAd "evaluation in context" eval() semantics behind it.

What's the goal? When do you need evaluation at parse time instead of runtime?

> 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 don't understand why macros allow configuration and lack of macros prohibit it. Can you explain more?

I think that one of the challenges in Condor is that--at least for users--it's not obvious when parse time is. Maybe in a configuration system it's obvious. But as ClassAds zip around between daemons, when does the evaluation happen? It has to be very clearly defined so that there isn't confusion. 

For instance, imagine a system administrator extends a startd's ClassAd using the new macro capability. I assume the stard evaluates it. But when the ClassAd goes to the Collector, is the macro syntax preserved (so it's re-evaluated at the collector), or is the new value substituted? And I believe the ClassAd is partially or fully re-created every time the startd does an update (is that right?) so is the macro re-evaluated then too? 

-alain