Rename rax server

Archives Ansible Project
1

Hi,

Is there any way to rename a rax server, using an ansible module? It doesn’t seem to be possible using the rax_meta module, and I couldn’t see anything else appropriate. I can do it in the control panel easily enough, so I assume it can be done through the API.

Thanks,

Graham

2

There is not. You have a few options:

  1. Delete it and build a new one with the new name
  2. Change the name in control panel, novaclient or similar

The ‘rax’ module doesn’t make changes to the servers after they are built, but rather that the servers themselves exist or not, which is in part why rax_meta exists for manipulating metadata at a later time.

3
  1. isn’t really an option (I want to rename my db replica after failover), so 2) will have to do for now. Is there any interest in adding this as a feature (somewhere)?
4

At this moment I’m not sure about adding it. In the end a name is just an uniqueness identifier. I personally tend to not track masters/slaves/replicas based on names, but instead check for functionality to make that determination. Connect to them all, run a check to see what they function is, use group_by to allow for easily targeting based on that check.

I wouldn’t consider a rename as something that should happen often.

5

I’m not sure I understand how that would work. Take the db example, if I want one primary and one replica, how would I go about that?

Currently, I’m using two different groups with exact_count, which is a bit weird. If there’s a better way, I’m keen to know about it.

6

This is just an example, and although I haven’t run it, it seems somewhat sane.

It does the following (using fake commands as an example):

  1. makes a determination of the database function of the host, by running some command that can tell you
  2. creates in memory groups based on the above info using group_by
  3. targets groups in subsequent plays to ensure master and slave configurations.

This prevents you from having to record, which server is which. You check for functionality, instead of relying on potentially wrong documentation, to perform things such as replica work on replicas. Following this you could easily expand to more complicated setups, that could even be used as automated remediation when an alert is fired that a host dies.

The ‘databases’ group is a list of all database servers and is specified in inventory.

  • hosts: databases

tasks:

Example script, may return ‘master’, ‘replica’, or ‘none’

  • name: Check database server functionality
    command: /usr/bin/master_or_replica
    register: database_function

  • name: Create in memory groups for database_function
    group_by: key=“database_{{database_function.stdout|trim}}”

  • hosts: database_none
    tasks:

  • name: Add host to master group if there is no master

add_host: name=“{{ inventory_hostname }}” groups=database_master
when: groups[‘master’]|default()|len == 0

  • hosts: database_master
    tasks:

  • name: Ensure master config and if needed become the master
    command: /usr/bin/config_master

  • hosts: database_none:database_replica
    tasks:

  • name: ensure replica config
    command: /usr/bin/config_replica
    when: inventory_hostname != groups[‘master’][0]

This is largely how my team handles our mongodb replicaset. I don’t personally care which is the master, I just care that ansible can figure it out and performs the right tasks on the right hosts.

7

OK, that’s interesting, but how would I set the servers up in the first place? This isn’t a cluster that elects a leader, I need to do different setup work on the primary and replica(s). I suppose I could arbitrarily decide that the first server in the db group was the primary the first time round, but that doesn’t feel much better than my current solution.