Upgrading

On this page:

Migration

Stage 3: Migration Process

Use these commands and scripts to complete the migration process.

  1. If you are upgrading from 2019.x.x run the following scripts. If not, go to Step 2.

    🛑 Later versions (2020.1.x and higher) do not require this first step.

    • JobsAndTasks migration script

      # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine
      # npm run migrate
    • JobsFrom20193 migration script

      ⚠ This script aids in migrating any active running jobs between major versions for certain scenarios. If proper procedure is followed and all jobs are paused, canceled, or completed, this script is optional.

      # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine/migration_scripts
      # node migrateJobsFrom20193.js
    • normalizeGroups script (2019.3 and higher)

      # cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine
      # npm run normalizeGroups
    • migration_scripts under Configuration Manager

      ⚠ This script upgrades all the old Golden Configs to Jinja2 Templates. If you have any Golden Configs at all and you are upgrading from 2019.x to 2020.2.x and higher, then this script is required.

      # cd /opt/pronghorn/current/node_modules/@itential/app-configuration_manager/migration_scripts
      # node migrate_to_jinja.js
  2. Run the following for Tags.

    # cd /opt/pronghorn/current/node_modules/@itential/tags/migration_scripts
    # node migrateTagRefs.js
  3. Audit (confirm) all Template Builder security dependencies (chroot, sudo, ldd) are installed and tested. These security dependencies are required for Template Builder to execute Jinja2 templates in a contained context.

    ⚠ For more information, see Template Builder Dependencies in the IAP Installation guide.

    • Install the shell utilities.

      yum -y install sudo chroot ldd
    • Verify the user that is used to run the server (usually pronghorn) is permitted to run sudo chroot without a password prompt. An example command which accomplishes this is shown below, but the system admin is expected to tailor this command to their environment. As long as the server is permitted to run chroot through sudo without a password prompt, Template Builder can sandbox Jinja2 template execution.

      echo "pronghorn ALL=(ALL) NOPASSWD: $(command -v chroot)" >> /etc/sudoers
    • Make sure Template Builder is permitted to copy in all dependencies required by Python. These dependencies are the output of the ldd command, as well as all paths in Python's internal sys.path constant. If file permissions prevent Template Builder from copying these files into its chroot jail directory, Python will not be able to execute within the sandbox subshell and Template Builder will execute in an insecure mode.

    • Verify IAP is running and examine the logs.

    • Template Builder will report that it is creating a sandbox directory for Jinja2 template execution, and when it is finished, it will report either success or failure.

    • Once Template Builder has finished initializing the sandbox directory, run a Jinja2 template.

    • Examine the server logs and look to make sure there are no warnings stating that Jinja2 execution is running in an insecure mode.

  4. Run index validation and confirm the latest indexing metrics.

    • Login to IAP and confirm you are able to view job details in the Active Jobs / Completed Jobs / Cancelled Jobs tabs from the Job Manager page.

      ⚠ If there are no job details and you get a Run Indexing Alert, resolve using the links below.

      How To Fix Indexing For
      Target Release 2020.1.x / 2020.2.x
      Target Release 2021.1.x

      Figure 4: Job Manager Indexing Alert

      Job Manager

  5. Navigate to the Job Details page in IAP to update and migrate jobs.

    • This step uses a Just-in-Time (JIT)/ OnDemand migration strategy, which puts job migration into the getJobDetails API. This means whenever a user displays the Job Details page, job migration occurs only when needed.

    • Confirm the Start Date, End Date and Assignee details are updated.

      Figure 5: JIT OnDemand job Migration

      Job Migration

Next Step

Go to Stage 4: Post-Migration to confirm all jobs have migrated.


Back to Stage 2: Staging

Home Page