Hooks: P2's Plugin Architecture

This page describes the lifecycle of a deploy as it is executed in the P2 preparer. Cluster-wide deploy operations will be explained in a different context.

Understanding the life of a deploy is crucial for using P2's plugin architecture system, hooks, correctly.

Hooks

P2 supports a special type of pod, called a hook, that can be scheduled like other pods. However, hooks are not executed as long-running processes but as scripts that are invoked at particular points in the execution lifecycle of a deployment. This allows P2 administrators the ability to plug into the deployment process at precise times to enable a variety of useful features.

Hooks are scheduled globally - when a hook is scheduled, every preparer will notice and install the hook. Hooks may not cancel the deploy process directly. This is a safeguard to prevent a bad hook from preventing further deploys on a cluster-wide level.

Hook writers are encouraged to write idempotent hooks as it is quite possible for the preparer to need to retry a deploy.

Types of Hooks

• before_install: Executes before any installation of new code or config.
• after_install: Executes after any installation of new code or config, but not before any old version of the application has been halted.
• before_launch: Executes after any installation of new code or config, and after any old version of the application has been halted, just prior to starting the new pod.
• after_launch: Executes after the new pod has been installed and started.
• after_auth_fail: Executes after the configured authorization policy has determined that the manifest or code is not authorized to be scheduled.
• before_uninstall: When a pod has been removed from a node, executes after the service has halted before its files are deleted.

Hooking Into The Deploy Lifecycle

The following steps occur serially for new manifests of a given pod ID, including if multiple pods of the same ID are scheduled concurrently.

• If an authorization policy is configured, the manifest is checked against the policy. If the manifest is not authorized, the after_auth_fail hook will be invoked. Note that at this point there is no guarantee that any code has been installed for inspection. If authorization fails, the deploy is canceled.
• The before_install hook is executed. This is an opportunity to perform automated operations required prior to starting the code installation process. If you don't have centralized user management, it is possible to create the pod user in this step.
• Any launchables described in the manifest are installed in the pod's directory. If installation fails, the deploy process will exit and try again. This will trigger the before_install hook a second time.
• The pod will verify the installation according to the auth policy. If verification fails, the after_auth_fail hook is fired. The deploy process will be canceled if authorization fails.
• The after_install hook is fired. Any prior version of the same pod (based on the ID) will continue to run at this point.
• The old pod is halted, if present.
• The before_launch hook is fired. At this point, no version of the pod is running.
• The new pod is launched. If this step fails, the deploy process is canceled and will be retried, starting from the before_install hook.
• The after_launch hook is fired.