Hi, The idea of immutable attributes looks totally cool!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?I guess we will introduce submit requirements to warn the users when they try to do something not allowed, but still rely on START expressions to enforce them reliably :)
Joan On 11/10/2015 07:05 PM, Brian Bockelman wrote:
On Nov 10, 2015, at 9:37 AM, Joan Piles <jpiles@xxxxxxxxxxxxxxxx> wrote: Hi all, We are thinking about using the new submit requirement features (now we use "START" conditions in execution nodes to enforce policies), and we wonder what would happen if we try something like this:SUBMIT_REQUIREMENT_NAMES=$(SUBMIT_REQUIREMENT_NAMES),MAXMEM SUBMIT_REQUIREMENT_MAXMEM=TARGET.RequestMemory < 8192 SUBMIT_REQUIREMENT_MAXMEM_REASON="The memory requested exceeds the maximum"and then a user submits a job requesting 4Gb of RAM, and before it starts running runs:condor_qedit 12345 RequestMemory 10240Would that be allowed? And if so... should it?Yes, it would be allowed - SUBMIT_REQUIREMENTS only covers the job at submit time. There is a patch for allowing admins to specify attributes that cannot be changed by users: https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=5065 That would somewhat help here. Ahem, Todd - any updates on the code review? :) Brian _______________________________________________ HTCondor-users mailing list To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a subject: Unsubscribe You can also unsubscribe by visiting https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users The archives can be found at: https://lists.cs.wisc.edu/archive/htcondor-users/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature