{section: Migration of CHTC from EL 6 to EL7}
-Every few years, when CHTC decides to migrate execute machines from one OS to another, we try to go to great effort to lessen the burden on users. This page tries to document the EL6 to EL7 migration to memorialize these issues for subsequent transitions.
+Every few years, when CHTC decides to migrate execute machines from one OS to another, we try to go to great effort to lessen the burden on users. This page tries to document the EL6 to EL7 migration to memorialize these issues for subsequent transitions in CHTC and for other sites.
{section: Requirements and Assumptions}
@@ -19,7 +19,7 @@
{section: The problem with defaulting}
-Ideally, we'd just as the users to put a clause in their requirements expression, selecting a particular platform, e.g.
+Ideally, we'd just ask the users to put a clause in their requirements expression, selecting a particular platform, e.g.
{code}
requirements = OpSysMajor == 7
@@ -28,3 +28,5 @@
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.
