[2.5, UI, UX] Adding a KVM pod over the UI doesn’t provide the option to skip commissioning pre-existing VMs

Bug #1696512 reported by Peter Sabaini on 2017-06-07
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
MAAS
Medium
Unassigned

Bug Description

UI enhancement: when configuring a virsh pod, maas immediately paves over existing KVMs without asking for confirmation. From a principle of least astonishment point of view maas should probably ask for confirmation before performing an operation that cannot be undone.

Version 2.2.0+bzr6054-0ubuntu1~16.04.1

Alvaro Uria (aluria) on 2017-06-08
tags: added: canonical-bootstack
Andres Rodriguez (andreserl) wrote :

Hi Peter,

This has been done by design and it is exactly the same behavior as to when we added a 'Virsh' Chassis. Since the 'pods' concept is that MAAS will manage all available resources, MAAS will commissioning whatever has been pre-created to correctly gather information on it.

Changed in maas:
status: New → Won't Fix
milestone: none → 2.3.0
Changed in maas:
milestone: 2.3.0 → none
Dean Henrichsmeyer (dean) wrote :

If that's by design, we should re-design it. It's poor UX. If you add a virsh POD that has existing KVMs it should error, not nuke data. At the very least there should be an exceptional confirmation where we warn them that there are existing KVMs and the data will be nuked.

Blake Rouse (blake-rouse) wrote :

No data will be nuked. We do not auto deploy the machines! The machine will just be commissioned to gather the VM's information.

Xav Paice (xavpaice) wrote :

So, commissioning a box does nothing at all to the disk on the machine? It does reboot the machine, which is far from ideal if you don't know that's going to happen.

From what I could tell testing yesterday, with a Maas 2.2.2 setup on Xenial, I added a pod using the virsh params for a machine which wasn't previously known to maas. There were two VMs already defined on that host, one for the maas service itself, and one named 'dhcp1'. Adding the pod left the maas VM alone (thankfully) and rebooted the dhcp1 VM into 'commissioning', after which it was left unable to boot normally. The VM has since been deleted and recreated, which means I am unable to tell the extent of what actually happened to it's disk image.

Changed in maas:
status: Won't Fix → Confirmed
milestone: none → 2.6.0
summary: - [2.2] UI: adding a virsh pod immediately commissions existing kvms
+ [2.5, UI] Adding a KVM pod over the UI doesn’t provide the option to
+ skip commissioning
tags: added: ui ux
summary: - [2.5, UI] Adding a KVM pod over the UI doesn’t provide the option to
+ [2.5, UI, UX] Adding a KVM pod over the UI doesn’t provide the option to
skip commissioning
summary: [2.5, UI, UX] Adding a KVM pod over the UI doesn’t provide the option to
- skip commissioning
+ skip commissioning pre-existing VMs
Dean Henrichsmeyer (dean) wrote :

Whether it nukes data or not, MAAS is taking something down that it did not create as a side effect of another action. At the very least there should be a confirmation required from the user acknowledging that it's going to happen and/or a way to opt-out of the commissioning of existing VMs.

Changed in maas:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers