add a playbook for automating migrations #13

New Issue

admin · 2026-07-14T19:55:10Z

admin commented

2026-07-14 19:55:10 +00:00

Write a playbook that allows for migration of services and other facts from one host to another. There are three possible approaches to implementing this playbook:

Abstracting the tasks in such a playbook via a new role other than roles/init-server, e.g. roles/migrate
Using already existing roles, e.g. roles/init-server, to for the migration playbook
Directly doing all tasks in such a playbook

In the second implementation case above, this would mean re-using variables, handlers or tasks in those roles, or otherwise extending them, to also fit the migration use-case. This is the best option if the playbook is written under the assumption that playbooks for creating and configuring the given hosts, based on the same role(s), were already run under this repo. That is, if one assumes that the migration is from a host with a predictable state due to use of playbooks in the same repo, as this would mean facts about the host to be migrated from share some values and semantics with variables and data structures already extant in given roles (especially role templates and role files) or variable files in the repo.

The first implementation case is best if no such assumption is made, provided some of the state information about the host to be migrated cannot simply be acquired through facts automatically gathered by Ansible. Since this may not be certain, it may be best to start with an implementation with the third approach, and then have periods of refactoring that lead the implementation into the first approach. This can be written as an initial migration is being manually attempted--that way, if a migration is needed one is not stuck waiting for completion of this implementation. So an active manual migration and an attempt to automate it in this way should run in tandem/parallel.

Write a playbook that allows for migration of services and other facts from one host to another. There are three possible approaches to implementing this playbook: 1. Abstracting the tasks in such a playbook via a new role other than `roles/init-server`, e.g. `roles/migrate` 2. Using already existing roles, e.g. `roles/init-server`, to for the migration playbook 3. Directly doing all tasks in such a playbook In the second implementation case above, this would mean re-using variables, handlers or tasks in those roles, or otherwise extending them, to also fit the migration use-case. This is the best option if the playbook is written under the assumption that playbooks for *creating* and *configuring* the given hosts, based on the same role(s), were already run under this repo. That is, if one assumes that the migration is from a host with a predictable state due to use of playbooks in the same repo, as this would mean facts about the host to be migrated from share some values and semantics with variables and data structures already extant in given roles (especially role templates and role files) or variable files in the repo. The first implementation case is best if no such assumption is made, provided some of the state information about the host to be migrated cannot simply be acquired through facts automatically gathered by Ansible. Since this may not be certain, it may be best to start with an implementation with the third approach, and then have periods of refactoring that lead the implementation into the first approach. This can be written *as* an initial migration is being manually attempted--that way, if a migration is needed one is not stuck waiting for completion of this implementation. So an active manual migration and an attempt to automate it in this way should run in tandem/parallel.

admin added the qol/feature label 2026-07-14 19:55:10 +00:00

admin self-assigned this 2026-07-14 19:55:10 +00:00

admin added this to the skato-ansible feature release project 2026-07-14 19:55:11 +00:00

admin pinned this 2026-07-14 20:08:08 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: admin/skato-ansible#13