Skip to content

Add pre ugrade hook #13288

@mickenordin

Description

@mickenordin

What would you like to be added

A new pre_upgrade_hooks variable in upgrade-cluster.yml, mirroring the existing post_upgrade_hooks. It should accept a list of task file paths and run them per-host inside the upgrade serial loop, right after needs_cordoning is set and right before the Node draining block in roles/upgrade/pre-upgrade/tasks/main.yml. Default is an empty list; behavior is unchanged unless the user populates the variable.

Why is this needed

Kubespray currently exposes post_upgrade_hooks for running custom tasks per-host after the kubelet/containerd upgrade but before uncordon. There is no symmetrical hook on the other side of the per-host upgrade window: between "we know this node will be drained" and "drain starts".

Several real use-cases need that earlier hook because they only work while the node is still hosting workloads:

  • Live-migrating OpenStack VMs off a compute node. Kubernetes drain only knows about Pods, so any libvirt VMs running under nova-compute are killed when nova-compute is evicted. A pre-drain hook lets us call openstack server migrate --live for every VM on the host before kubespray touches it, so OpenStack tenants survive cluster upgrades.

  • Disabling scheduling at the workload layer. OpenStack's compute service disable,
    cluster-autoscaler holds, BGP peer drain, and similar operations are best done before pods start being evicted so downstream traffic shifts cleanly.

  • Pre-flight checks that need the node "live". Drain-readiness probes, stateful-client coordination, or just a "is anything irreplaceable running on this node" gate are easier when the node is still in its normal state.

Today there is no clean way to do any of this without forking kubespray or wrapping ansible-playbook in expect. A small symmetrical change to add pre_upgrade_hooks keeps the upgrade flow native and makes upgrades safe for workloads that have meaningful state outside of Kubernetes itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions