{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.

{section: Requirements and Assumptions}

The transition must be gradual, and staged, so that users with old jobs that cannot run on the old OS can run to completion on a subset of the pool at the same time that users with jobs that can only run on the new OS can make progress.

If a user specifies nothing extraordinary, their jobs will run on the "default" OS, which initially is the old, and at some point in time is switched to the new.

During the transition, some jobs will only run on the old os, some jobs only on the new, and some (many?) on both, and the user needs to be able to opt into any of these three cases.

This transition applies to

*: Jobs submitted from CHTC-managed schedds, running on CHTC-managed execute nodes
*: Jobs submitted from non-CHTC managed schedds, running on CHTC-managed execute nodes (jobs flocking in)
*: Jobs submitted from CHTC-managed schedds, running on non-CHTC-managed execute nodes (jobs flocking out, and glideins)

The HTCondor religion is that execute nodes advertise what they *are*, and it is the responsibility of the jobs to select what the *need*.  If a job selects the wrong OS to run on, that's on the job, the startd should not care.  *However*, pragmatically, we may need to implement policy on the execute node in the case where it is the only place that CHTC has control.

{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.

{code}
requirements = OpSysMajor == 7

or

requirements = ((OpSysMajor == 7) || (OpSysMajor == 6))
{endcode}