When and How CC Updates the Runtime

Introduction

There are multiple paths through which CC updates the runtime (Diego or Eirini). There are multiple paths and they can be hidden and circuitous. As a result, it can be difficult to reason about whether an API interaction will update the runtime.

Overview

The two main methods for updating the runtime are the ProcessObserver class and the Diego::Sync job. The ProcessObserver triggers when certain fields are updated on processes and immediately update the runtime. The Diego::Sync job runs periodically and will update the runtime if certain fields have changed on the process.

Details

Process Version

To understand if a change to a process will automatically propagate to the runtime, one must first understand process versioning. When one or more of a specific set of fields are updated, then the process's version will be updated to a new random guid. Changing a process's version will then result in the process's LRP changing as will be demonstrated in coming sections.

Process Observer

ProcessObserver triggers when changes to processes are committed to to the database. It is called using after_commit hooks in the after_save and after_destroy model hooks.

Note: Because most of Cloud Controller unit tests depend on database transactions, these after_commit hooks don't trigger in tests, unless you switch the test's database isolation to :truncation.

If the process's state, diego, enable_ssh, or ports fields are updated the the ProcessObserver will start or updated the process. Note that this method name is a bit confusing, because, as we will see, the Runner.start method will also update running processes.

Focusing on the Diego case, Diego::Runner#start directly forwards on to Diego::Messenger#send_desire_request, which then forwards on to the Diego::DesireAppHandler.create_or_update_app, where it is finally revealed that we will also be updated an existing process, not just creating new processes.

Sync Job

Manifests

Restart Action

Tasks

Deployments