Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow pcs cluster allowed_node_changes to accept all kind of changes #34

Open
Dzordzu opened this issue Nov 18, 2020 · 3 comments
Open

Comments

@Dzordzu
Copy link

Dzordzu commented Nov 18, 2020

Currently there are supported the following options:

  • add
  • remove
  • none

It would be a nice feature to add an all option that will allow to add and remove nodes within a single shot

@OndrejHome OndrejHome self-assigned this Nov 20, 2020
@OndrejHome
Copy link
Owner

Hello @Dzordzu,
Thank you for using the modules and suggesting a change.

My concern here is that with all option the pcs_cluster module would have "fix" an order in which things are happening or would have to make sure to apply them in right order. It would still be possible to just use multiple tasks with single change to achieve whatever order one desires, but that is also possible now.
Therefore I have some question:

  1. Assuming that all option existed could you give me an example of what behaviour you would expect from it? (what actions would happen in what order)
  2. One alternative I can think of now is allowing composition of changes such as add,remove (first add all new nodes, the remove undesired nodes) or remove,add(first remove undesired nodes, then add new ones) to allow grouping changes in one invocation of pcs_cluster. Would this address your use case?
  3. Would it be possible to share example tasks that you have used (and any workarounds) to achieve behaviour you wanted to have? (in case that such configuration should not be public, you can send it via email - [email protected] - I will not make them public in such case)

@Dzordzu
Copy link
Author

Dzordzu commented Nov 20, 2020

Hello @OndrejHome,

For me an option suggested in 2) will be ideal. The user should be able decide about the order of the changes. Obviously in most cases the order would be remove and then add

When it comes to workaround, I have to use pcs_cluster twice (first time it didn't work, dunno why).

- name: PCS auth
  pcs_auth:
    node_name: "{{ hostvars[item]['ansible_fqdn'] }}"
    password: "{{ dpm_pcs_password }}"
  with_items: "{{ play_hosts }}"

- name: Setup cluster via pcs (remove nodes)
  pcs_cluster:
    allowed_node_changes: remove
    state: present
    cluster_name: "{{ dpm_cluster_name }}"
    node_list: "{% for i in play_hosts %} {{ i }} {% endfor %}"

- name: Setup cluster via pcs (add nodes)
  pcs_cluster:
    allowed_node_changes: add
    state: present
    cluster_name: "{{ dpm_cluster_name }}"
    node_list: "{% for i in play_hosts %} {{ i }} {% endfor %}"

- name: Start cluster services on all nodes
  service:
    name: "{{ item }}"
    state: started
  with_items:
    - pacemaker
    - corosync

- name: Enable services on start
  systemd:
    name: "{{ item }}"
    state: started
    enabled: true
  with_items:
    - pacemaker
    - pcsd
    - corosync

@OndrejHome
Copy link
Owner

Hello @Dzordzu,
Thank you for response and example playbook you use.

Two more questions:

  1. How does your cluster look like before running this playbook? (for example: 2-node cluster with nodes 'node1' and 'node2')
  2. Which hosts you have your inventory for this playbook? (for example: play_hosts="node2 node3")

I will have a look in the meantime on how the option 2) could be implemented - note while this might take some time I will keep you updated on progress.

Thank you for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants