Re: [HTCondor-users] Submit Requirements and condor_qedit

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

> The idea of immutable attributes looks totally cool!
	There's another ticket (link below) which discusses other options 
at greater length, although immutable attributes seems like a good 
approach and has some other nice uses.
https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=4898,109

> However, I also wonder what would happen (both with submit requirements and 
> with immutable attributes when the attribute is evaluated at matchmaking:
> > request_memory = TARGET.Memory
> Would it be possible to still limit it somehow?
	It depends on how, exactly, we would define "immutable" -- the 
obvious approach would be that the unevaluated attribute couldn't change, 
in which case simply making request_memory immutable wouldn't be enough. 
On the other hand, in some cases -- like requirements -- you really don't 
want to require that the evaluated result never changes.
	I don't know if that's an argument for different types of 
immutability, or if it's an argument for combining submit requirements and 
immutability.  The problem is a setting like
request_memory = IfThenElse( TARGET.Memory =!= undefined, TARGET.Memory, 1 )

which will be accepted by the submit requirement (since it'll be 1) but 
still arbitrarily large at matchmaking.
	On the other hand, if we take the point of view that submit 
requirements exist to help the user -- because enforcement actually 
happens at the startd -- I don't worry about a user deliberately bypassing 
the submit requirements and stepping on the startd landmine (so to speak), 
instead.
- Todd