remove_host module

[cornim]

Proposal: remove_host module

Author: Cornelius Mund <@cornim>

Date: 2019-20-22

• Status: New
• Proposal type: module
• Targeted release: soonish?
• Estimated time to implement: no too long?

Motivation

Allows to dynamically remove hosts from inventory and therefore also from all groups. This would all to better manage dynamically manage the hosts in a playbook. Basically this is the reverse functionality to the add_host module

Problems

What problems exist that this proposal will solve? Currently the only way to dynamically remove a host is to edit the inventory file and run meta: refresh_inventory but complicated file modifications often times require os depended tools and make the ansible scripts less portable.

Solution proposal

    - remove_host:
        - host_id1
        - host_id2

This removes the hosts dynamically while running the playbook.

Documentation (optional)

A module documentation would make sense

[ansiblejunky]

Hi @cornim , I am interested in this proposal but having a hard time understanding a high level business use case for developing a module to remove hosts. The meta: refresh_inventory mainly exists to allow you to perform one or more add_host tasks and then immediately afterwards do a task to meta: refresh_inventory and then start performing tasks against this new inventory. The important benefit here is that we don't have to start a new Play in the Playbook, which was previously necessary when using add_host. This also allows us to use the add_host task within an Ansible Role and be able to perform a set of tasks immediately on the newly added hosts.

When it comes to removing hosts, typically I find that in most use cases that I have dealt with or seen we simply start a new Play targeting a limitation of hosts using patterns.

Can you provide a good business or technical use case?

In a simple sense, when would a set of Ansible tasks want to remove_host and then continue targeting the remaining hosts? Normally we go with a "desired state" concept with Ansible. So when I start , for example, Ansible playbook I have a desire to deploy Application X on all of my app servers. Why would I remove an app server from the list? If my inventory file or dynamic inventory is defined nicely, then the Play should target [app_servers] group and it should not need any other logic to handle exceptions or cases when I should remove a specific server. I feel that type of logic should not be in a Playbook/Role, but rather one should consider whether this is an SOE (Standard Operating Environment) issue or whether you should have different groups or child-groups defined?

[cornim]

Hi @ansiblejunky, the case for me was pretty simple. I was using ansible with aws and wanted to have an inventory with a list of current machines that I could start/stop, etc. As the dynamic aws inventory online lists machines that are started, I wrote a jinja2 template to auto generate inventory files from the in memory inventory. Now writing playbooks which added hosts to inventories and hence inventory files was no problem with this approach but terminating a host and removing it from an inventory file was always a manual process. Hence the proposal. Let me know if you have any additional questions.

[ansiblejunky]

Why do you need to generate inventory files? Why not simply use dynamic inventory plugin to get the data from AWS to use as the target nodes. Then perform the actions and finish the playbook. For example: ansible-playbook -i aws.yml playbook.yml Or, for terminating hosts.. ansible-playbook -i aws.yml terminate.yml The terminate.yml playbook would determine with some logic what servers need to be terminated. Once it's terminated, you move on to the next host you want to terminate. Once all are terminated, complete the playbook. I guess I still don't see the need to remove the host from in-memory. Also, if you are generating inventory files and then using these files to target servers using a playbook, you still wouldn't need to remove the host from inventory from within the playbook/role. Just terminate the target host, and then move on to the next targeted host.

[cornim]

If my memory serves, the dynamic inventory does not show hosts when they are stopped and is therefore not usable to stop and at a later point start instances. For this you I created "offline" inventory files.

[bcoca]

@cornim that is probably due to the specific inventory source you are using, there are many plugins and scripts and they all have different behaviour.

[cypriani]

Because of ansible/ansible#77944, the refresh_inventory workaround is gone, which makes a remove_host module much needed than ever.

Here's another use case: the process of creating a new OpenShift cluster involves a temporary bootstrap node. Since it's temporary, I don't want it in my inventory; instead I'm using add_host, then delete the temporary VM when it's not needed any more. But there are still operations to be performed which expect that all the known hosts be up and running.

[bcoca]

2.18 will introduce a good way to have a 'transactional update' to inventory.

After that hits I'll be revamping how refresh_inventory works. Specifically to apply only to 'next play' .. right now it does a mix of adding data to current but not really altering current.

That will also allow for 'remove_host' to be implemented in a sane manner (also to apply to 'next play' only).