Nova database schema compatibility boundary after failed rolling upgrade

Goal is to define a safe operational boundary for Nova when a rolling upgrade fails after database migrations have been applied but before all compute and API nodes are updated.

The upgrade process relies on rolling updates for availability, and Nova requires schema version compatibility between API and database. Migrations can be additive or destructive, which creates tension between the desire for automated rollback and irreversible schema changes.

The permission boundary for starting services against a newer schema is not clearly documented for partial rollback scenarios. Clarity is needed on when a service start is considered safe versus when it must be blocked.

What constraint determines Nova API start eligibility against a newer database schema? Under what conditions is a partial rollback considered unsupported without restoring the database? Is there a documented configuration that enforces a schema version check before service start?