Overview

The OCCP introduces a concept of "Configuration Phases" which allow scenarios to be more easily customized while staying consistent and being reasonably fast to deploy. There are two phases in the OCCP named Phase 1 and Phase 2, which are applied to Base VMs by the Administrative VM to deploy the desired scenario VM. When a machine is said to be "phase 1" or "phase 2" it means that the machine has completed that phase.

Phase 1

This phase is meant to be applied by the scenario contributor and has the main purpose of installing software. More generally this phase is best suited for operations that take time, depend on certain conditions (such as packages in a repository at the time of application), or other configurations that will be altered by the scenario user. At the end of this phase the Administrative VM still has the ability to remotely access and configure the VM.

Phase 2

This phase is meant to finalize the VM for the scenario to use and is meant to be applied by the scenario runner. It will make any required changes to configuration files, transfer static content, add users, and any other action that is independent of the time of application and may be reconfigurable by the scenario user. Once this phase is applied the Administrative VM's ability to reconfigure the machine is removed and is considered final. To reconfigure the VM it must be reverted to phase 1 then have phase 2 reapplied.

What are the benefits to this?

While it does seem like more work to configure machines this way, it allows you and the community greater flexibility and reuse later on. The goal of phase 2 is to provide subtle configuration changes that don't change the underling workings of the scenario. This could be useful for running the "same" scenario multiple times but change subtle things such as usernames, passwords, ssh keys that prevent participants from just memorizing small details from the last time they saw the scenario. Additionally you could change up webpage content or other such details that further the illusion that the scenario is a different one so that the participants need to again workout the correct solutions. By the phase mechanism and use of ContentPacks makes it so small changes can be made by editing a few files and not touching any VMs directly.

Next, when scenarios are packaged they are done so with the phase 1 VMs. This cuts down on installation time because the time consuming process of downloading and installing packages is already done. Furthermore it ensures that the versions are exactly what the scenario contributor intended which could be crucial for some scenarios.

Other "Phases"

In addition to phase one and two, there are intermediate helper phases. These are really only phases in that they are using a similar mechanism but a VM will never be considered "at" one of these phases like they would be for phase one or two.

poweroffp1

This follows phase 1 immediately and is tasked with gracefully shutting down the VM. It would also allow future growth if it is discovered additional tasks should be completed just after phase 1 runs but before the snapshot is taken.

poweroffp2

This follows phase 2 immediately and is tasked with gracefully shutting down the VM and cleaning up any lingering OCCP framework not appropriate to be present during the scenario, such as removing puppet.

hostname

This phase happens just before phase 2 and is tasked with setting the hostname of the VM. Some phase 2 aspects might rely on the system reporting the hostname correctly and cannot just use the OCCP_hostname variable. When a domain is specified it will set the FQDN. Anything in phase 2 can rely on this phase happening first and can make the assumption that the hostname is set already.