[2018.2.0-rc2] Orchestration of group where a node is not a VM continues with orchestration

[ColonelPanicks]

It seems the inheritance or checking of whether a node is a VM or not is done at the group level.

Create group nodes with node[001-100] with VM setup:

[root@controller [testcluster] ~]# metal configure group nodes
<snip>
Indicate whether a node or group is a VM (21/64) [yes/no]  |yes|

Enter the IP or hostname of the Libvirt host (22/64)  |10.10.0.1|
10.10.0.11
Amount of memory to allocate to a VM in GiB (23/64)  |4|

Number of CPU cores to allocate to a VM (24/64)  |1|

Size of the VM root disk to allocate in GB (25/64)  |60|

Specify the Libvirt disk pool name (26/64)  |local|

Specify the Libvirt disk pool path (27/64)  |/opt/vm|
<snip>

Configure a node in the group to not be a VM

[root@controller [testcluster] ~]# metal configure node node001
<snip>
Indicate whether a node or group is a VM (21/64) [yes/no]  |yes|
no
<snip>

Orchestrate the node:

[root@controller [testcluster] ~]# metal orchestrate create node001
Provisioning new storage volume for node001
Provisioning new machine node001
[root@controller [testcluster] ~]# metal orchestrate create node002
Provisioning new storage volume for node002
Provisioning new machine node002

I would expect that node001 would be seen as not being a VM as is_vm is now set to false.

[ColonelPanicks]

By extension, this causes power commands to behave weirdly for node001 as it does not believe the node is a VM.

[root@controller [testcluster] ~]# metal power node001 status
error: BMC network not defined for node001. Use --trace to view backtrace
[root@controller [testcluster] ~]# metal power node002 status
node002: Power state: off

[sierra-tango-echo]

Again, hold off on these (unless we suspect they are not pre-exisiting) we'll do a refactor in the next release, the current asset project is largely intended to provide the necessary info so we can implement this sort of feature more appropriately