Renaming a host¶

Deptool encourages reprovisioning over renaming hosts. Renames often have far-reaching unintended consequences. Having said this, even though initial provisioning is fast with Deptool, reprovisioning is not always feasible, especially when a host holds state that is difficult to move. This chapter explains how to handle host renames with Deptool.

Safety checks¶

Deptool computes the deployment plan offline, based on the config tree, and tracking refs per host. When you rename a host, the base for this diff is no longer accurate, and the plan can be misleading. In the best case, the hostname is new, and the renamed host shows up as a new host in the plan. During the lock phase Deptool then detects that the host was not new after all, and in the next run the plan is correct. And although reusing an old hostname on an existing host is ill-advised, Deptool even handles swapped hosts.

Historical note¶

Up to version 1.2, Deptool used a different store format that made renames more complicated. This restriction has been lifted in version 1.3. For hosts that are still on store format 1, Deptool still refuses to deploy after the host has been renamed. Run deptool reapply --host once against it before the rename to upgrade the host’s store to version 2, after which a rename is possible.