requirements = ((OpSysMajor == 7) || (OpSysMajor == 6))
{endcode}
-However, there are a couple of problems with that. The first problem is defaulting. When a has requirements that don't mention OpSysMajor, the submit side needs to add in a clause picking one. This is what condor_submit does today with OpSys and Arch. This is hard-coded into the condor_submit executable, and is difficult to replicate in configuration, *but it is possible*, though ugly. We can simulate this today in config which looks for the string OpSysMajor in requirements, and if it is there, we can assume that the job is correctly selecting a version. One can construct all kinds of expressions for which this isn't true, but it should work in practice, as it does for OpSys and Arch.
+However, there are a couple of problems with that. The first problem is defaulting. When a has requirements that don't mention OpSysMajor, the submit side needs to add in a clause picking one. This is what condor_submit does today with OpSys and Arch. This is hard-coded into the condor_submit executable, and is difficult to replicate in configuration, *but it is possible*, though ugly with the new submit transforms. We can simulate this today in config which looks for the string OpSysMajor in requirements, and if it is there, we can assume that the job is correctly selecting a version. One can construct all kinds of expressions for which this isn't true, but it should work in practice, as it does for OpSys and Arch.
+
+{section: Submit Requirements trickery}
+
+Using existing submit requirements, we can make the default "6" by configuring the schedd thus:
-Using existing submit requirements, this can be done with
{code}
JOB_TRANSFORM_NAMES = EL, EL_VER
JOB_TRANSFORM_EL @= end
-[
- Requirements = Regexp("OpSysMajorVer",UnParse(Requirements),"i") =?= false;
- copy_Requirements = "OrigRequirements";
- set_Requirements = (Target.OpSysMajorVer == 6) && OrigRequirements;
- set_AmTransformed = true;
-]
+
+REQUIREMENTS Regexp("OpSysMajorVer",UnParse(Requirements),"i") =?= false
+SET Requirements (Target.OpSysMajorVer == 6) && $(MY.Requirements)
+SET AmTransformed true
+
@end
+{endcode}
+
+We can even extract the version requested, and insert it into a standalone attribute by configuration like this:
+
+{code}
+
JOB_TRANSFORM_EL_VER @= end
[
eval_set_WantELVer = isError(int(Regexps("OpSysMajorVer == ([0-9])", UnParse(Requirements), "\\\\1", "i"))) ? 0 : int(Regexps("OpSysMajorVer == ([0-9])", UnParse(Requirements), "\\\\1", "i"));
@@ -50,8 +58,12 @@
@end
{endcode}
-Note that relying on a regexp match of an UnParse is suboptimal. We can then add in 8.7.x a classad ContainsAttr function that returns true iff the expression references (directly or indirectly) some named attribute. This would make the code more robust and simpler.
+Note that relying on a regexp match of an UnParse is suboptimal. We can then implement in 8.7.x a classad ContainsAttr function that returns true iff the expression references (directly or indirectly) some named attribute. This would make the code more robust and simpler.
These expressions simplify the Requirements expression, and obey the principle of least surprise for our users -- when they request a OpSysMajorVer, no changes are made to their requirements.
Also note the EL_VER, which can be used by GlideinWMS to extract into a simple attribute which version is being requested. This could also be used in a docker, VM, or singularity environment to create a machine of a given type.
+
+{section: Schedds CHTC does not manage}
+
+This does not impact schedds that schedd does not manage. We could either ask them to implement this configuration, which presumes an 8.6 condor schedd. Or, we could implement policy on chtc execute nodes to only allow jobs from unmanaged schedds on a certain distro.
