Mark broken / fixed issues

Bug #1871021 reported by nb
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
MAAS
Status tracked in 3.6
3.5
Won't Fix
Medium
Unassigned
3.6
Triaged
Medium
Unassigned

Bug Description

maas <user> version read
{
  "capabilities": [
    "networks-management",
    "static-ipaddresses",
    "ipv6-deployment-ubuntu",
    "devices-management",
    "storage-deployment-ubuntu",
    "network-deployment-ubuntu",
    "bridging-interface-ubuntu",
    "bridging-automatic-ubuntu",
    "authenticate-api"
  ],
  "version": "2.7.0",
  "subversion": "8232-g.6e1dba4ab-0ubuntu1~18.04.1"
}

### Issue 1 ###
Info:
Marking a machine broken and then fixed changes values that should not be changed.

Steps to reproduce:
- Deploy a machine
- Grab machine details: maas <user> machine read <machine> | jq . > orig.json
- Mark as broken
- Mark as fixed
- Grab machine details: maas <user> machine read <machine> | jq . > after-changes.json
- Observe changes: vimdiff orig.json after-changes.json

Example of changed attributes:
"hwe_kernel": "ga-18.04" -> "hwe_kernel": null
"netboot": false -> "netboot": true
"osystem": "ubuntu" -> "osystem": ""
"distro_series": "bionic" -> "distro_series": ""
"current_installation_result_id": 4036 -> "current_installation_result_id": null
"owner": "<user>" -> "owner": null

Expected Results:
None of those attributes should change unless they were adjusted while the machine was marked as broken. This further complicates web UI feedback; owner, OS, and distro are not properly shown.

I believe this bug is related to: https://bugs.launchpad.net/maas/+bug/1381213

### Issue 2 ###
Info:
I am attempting to change the network interface on a machine to another vlan/subnet.

Steps to reproduce:
REQ: At least two vlan/subnets available...
- Deploy a machine with a single network interface on 1st vlan/subnet (10.11.28.0/24)
- Mark as broken
- Change vlan/subnet to second vlan/subnet (10.11.29.0/24)
- Mark as fixed
- Power on machine
- Observe that the MAAS controller gives the old IP from the 1st vlan/subnet, while the new vlan is set.

Expected Results:
Network interface acquires new IP from the new vlan/subnet

I think this issue relates to MAAS not dropping the machine's IP from the MAAS controller dhcp.leases file. There are probably other locations that MAAS is tracking an IP, but my knowledge of the MAAS database back end / mechanics is nil. It seems as though the controller isn't releasing the IP back to the pool.

My environment looks like:
MAAS Controller:
- IP - 192.168.1.2
- GW - 192.168.1.1

1st vlan/subnet:
10.11.28.0/24
VLAN ID: 200

2nd vlan/subnet:
10.11.29.0/24
VLAN ID: 201

PfSense router with dhcp-relay pointing to 192.168.1.2

MAAS Controller pointing 1st and 2nd vlan/subnet DHCP to MAAS subnet with DHCP Relay

I can provide PCAPs, screenshots, logs if needed. I believe /var/log/syslog or regiond.log is capturing DHCP leases also.

Revision history for this message
Björn Tillenius (bjornt) wrote (last edit ):

The bug here seems to be that when you mark a deployed machine as broken, it should still be considered deployed (and broken).

tags: removed: broken dhcp fixed mark
Changed in maas:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

MAAS should not lose information when a machine is marked as broken, nor allow to edit certain properties of a machine marked as broken if these properties cannot be changed when a machine is deployed and healthy.

Regarding issue #2 - if you need to change properties of a machine, re-deploy it with a different configuration instead of making manual changes. This would be a "won't fix" issue. In the future, please submit separate issues.

Changed in maas:
milestone: none → 3.4.0
Alberto Donato (ack)
Changed in maas:
milestone: 3.4.0 → 3.4.x
Revision history for this message
John Puskar (jpuskar-amtrust) wrote :

Needing to redeploy a KVM host in order to add a new VLAN is a crazy limitation.

Changed in maas:
milestone: 3.4.x → 3.5.x
Revision history for this message
Christian (flyinghuman) wrote :

The Issue affects me too. Marking a Machine Broken and then fixed afterwards deleted all the informations and i'm unable to mark it broken again.

Initially i only want to change the network bonding mode in MAAS after we had some issues with the initial configuration and run into that issue.

Revision history for this message
Oscar (imherenow) wrote :

After marking the node as fixed you have to run the Test, after test passes it is again possible to mark it as Broken and the owner shows up again. Not sure if there is other data missing or not, everything seems fine after running Test.

Revision history for this message
Felipe Alencastro (falencastro) wrote :

After marking a machine as broken this was what I had to do in order to restore it to it's previous state:

update maasserver_node set owner_id=5, osystem='ubuntu', distro_series='jammy', hwe_kernel='hwe-22.04', agent_name='37e6a200-908d-464d-85bb-fcc7cf12d6e8', netboot='f', current_installation_script_set_id=1538, enable_hw_sync='t' where system_id='ru3chp';
insert into maasserver_filesystem ("created", "updated", "uuid", "fstype", "label", "mount_point", "acquired", "partition_id", "block_device_id", "filesystem_group_id", "create_params", "cache_set_id", "mount_options", "node_config_id") values ('2024-02-21 19:02:52.970848+00', '2024-02-21 19:02:52.970848+00', 'e01f283f-0c3e-4724-98d6-233470798bcc', 'fat32', 'efi', '/boot/efi', 't', 737, NULL, NULL, NULL, NULL, NULL, 218);
insert into maasserver_filesystem ("created", "updated", "uuid", "fstype", "label", "mount_point", "acquired", "partition_id", "block_device_id", "filesystem_group_id", "create_params", "cache_set_id", "mount_options", "node_config_id") values ('2024-02-21 19:02:53.024758+00', '2024-02-21 19:02:53.024758+00', '99f89676-a456-48c6-a4c0-d4a4df7745b2', 'ext4', 'root', '/', 't', NULL, 578, NULL, NULL, NULL, NULL, 218);
update maasserver_staticipaddress set ip='192.168.0.120' where id=13179;
insert into maasserver_interface_ip_addresses ("interface_id", "staticipaddress_id") values (5982, 13179);

The last two have to be done for each ip address the machine has.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.