[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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), instead.

- Todd