feat(xo-server): ability to manage VIFs using REST API when creating a VM

[MathieuRA]

Description

Previously, we destroyed all VIFs then xo-web sent the VIFs created by the user + the template's VIFs and xo-server creates all the VIFs sent by the user. This behavior was a bit weird, but since we mainly use xo-server with xo-web, it wasn't a problem. This behavior meant that creating a VM from the REST API did not create the VIFs of the VM template.

This PR changes the handling of VIFs when creating a VM. Instead of deleting all VIFs and only creating the VIFs sent by the client, the VIFs template are not removed. There is always the possibility of removing a VIF from the template by passing the destroy parameter with the VIF's device. {device: <vif-device>, destroy: true} To edit a VIF of the template, simply pass the device the information: {device: <vif-device>, ...all other vif fields

Example

// the VM will be created with the template's VIFs
xo-cli rest post pools/<your-pool-id>/actions/create_vm \
name_label="mra-vm-from-rest-api" \
template="<your-template-id>"

// the VM will be created with the template's VIFs + one VIF
xo-cli rest post pools/<your-pool-id>/actions/create_vm \
name_label="mra-vm-from-rest-api" \
template="<your-template-id>" \
vifs=json:'[{"network":"<your-network-id>"}]'

// the VM will be created with the template's VIFs but the VIF with `device 0` will be updated
xo-cli rest post pools/<your-pool-id>/actions/create_vm \
name_label="mra-vm-from-rest-api" \
template="<your-template-id>" \
vifs=json:'[{"device":"0", "network":"<your-network-id>"}]'

// the VM will be created with the template's VIFs but, the VIF with `device 0` will be removed
xo-cli rest post pools/<your-pool-id>/actions/create_vm \
name_label="mra-vm-from-rest-api" \
template="<your-template-id>" \
vifs=json:'[{"device":"0", "destroy": true}]'

Checklist

• Commit
  • Title follows commit conventions
  • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
  • If bug fix, add Introduced by
• Changelog
  • If visible by XOA users, add changelog entry
  • Update "Packages to release" in CHANGELOG.unreleased.md
• PR
  • If UI changes, add screenshots
  • If not finished or not tested, open as Draft

Review process

This 2-passes review process aims to:

• develop skills of junior reviewers
• limit the workload for senior reviewers
• limit the number of unnecessary changes by the author

1. The author creates a PR.
2. Review process:
   1. The author assigns the junior reviewer.
   2. The junior reviewer conducts their review:
      • Resolves their comments if they are addressed.
      • Adds comments if necessary or approves the PR.
   3. The junior reviewer assigns the senior reviewer.
   4. The senior reviewer conducts their review:
      • If there are no unresolved comments on the PR → merge.
      • Otherwise, we continue with 3.
3. The author responds to comments and/or makes corrections, and we go back to 2.

Notes:

1. The author can request a review at any time, even if the PR is still a Draft.
2. In theory, there should not be more than one reviewer at a time.
3. The author should not make any changes:
   • When a reviewer is assigned.
   • Between the junior and senior reviews.

[fbeauchamp]

I think modifying the existing api is risky, and would keep the behaviour with the rest api : creating a VM will purge vifs of an existing template I also think vifs can be added by a subsequent call , or may be recreated if they are givin in the rest api call parameter

@pdonias what is your opinion ?

[pdonias]

@fbeauchamp What do you mean by "it would keep the behaviour with the rest api : creating a VM will purge vifs of an existing template"? From my understanding, with the new behavior, calling the API method without passing vifs would keep all the template's VIFs, right?