Server management

[ylei-tsubame]

This is the issue for tracking additional UI issues related to enabling server management in the UI. It does include building the forms, etc. (UI elements) to enable the server management tasks.

• [ ] #352
• [x] #562
• [ ] #668
• [x] #685
• [ ] #686
• [ ] #696
• [x] #713
• [ ] #731
• [ ] #739
• [ ] #740

[digimer]

From one of our maritime clients; Required for migration from M2 to M3;

• Start / stop / reboot / migrate VMs
• Delete VMs
• Withdraw a node (anvil-safe-stop), this already exists but needs to have the confirmation added.

[ylei-tsubame]

Subnodes

• Cold stop: anvil-safe-stop --stop-servers --poweroff
• Each subnode should be able to join node

  Nodes and subnodes status:

  • node state/status: optimal when both subnodes are online, degraded when 1 or more subnode didn't complete all its states, offline when no subnodes completed its states.
  • subnode status/state: join, in_ccm, crmd (descriptions in Cluster.pm:3627); the subnode is online when it completes all its states, otherwise, it's not ready
  • total cpu cores*sockets (with separates cores, sockets values)

    Anvil operations

  • cold stop anvil (cold stop all nodes)
  • power on anvil (power on all nodes)
  • shut down all servers (shut down servers across all nodes)
  • boot all servers (boot servers across all nodes)

    Nodes and subnodes operations

  • cold stop node (shut down everything sequentially)
  • power on node (when both nodes are off)
  • power on for 1 subnode; keep the word choice because boot/shut down is for servers
  • power off for 1 subnode
  • start node (when both nodes are not in cluster)
  • join node for 1 subnode
  • withdraw for 1 subnode
  • fence/force reboot for 1 subnode; dangerous op

    Server status

  • allocated cpu cores*sockets (with separates cores, sockets values)
  • allocated memory
  • allocated storage (1 or more volumes); each volume has: volume number, connection (for each subnode), role (for each subnode), disk state (for each subnode), disk size
  • network (1 or more networks); bridge (show which network the server is connected to, i.e., ifn/bcn), driver (i.e., virtio), mac address (use mac to get ip from network_interfaces), ip address; look in anvil-report-usage to see how the server data is collected
  • might want to have a detailed view of the server list that includes more info

    Server operations

  • graceful shut down (2 word)
  • graceful shut down all
  • force reboot; dangerous op
  • boot
  • migrate; just migrate to subnode that the server isn't currently running on; disable when the target server is already migrating
  • migrate all to subnode; if all servers are on 1 subnode, simply migrate all servers to the other; but if there are servers across both subnodes, ask the user which is the target
  • also allow the user to choose between migrating in parallel or in series (one-by-one)
  • delete; dangerous op; make the user type the name of the server to confirm the deletion

[digimer]

Force-off/reboot VMs is already supported with anvil-shutdown-server --server <foo> --immediate.

[digimer]

@ylei-tsubame - For the 'force off' / 'force reboot' of the host, striker-boot-machine can take the switches --force-off or --force-reboot. Alternatively, you can set task=force-{off,reboot} as part of the job_data.

[digimer]

Stopping all servers at once is done with anvil-shutdown-server --server all.

[digimer]

Added #352 here as the back-end is done (barring bugs), and so is ready for UI integration