[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Submit Requirements and condor_qedit
- Date: Wed, 11 Nov 2015 15:36:52 -0600 (CST)
- From: Todd L Miller <tlmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Submit Requirements and condor_qedit
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.
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),