- QUADS version (latest)
- Operating System: F4x
Describe the bug
The scenario is as follows. The allocation has a number of hosts. One of these hosts fails with hardware issues (e.g. faulty drive). The system schedule is then shrunk, and the system is replaced with another host. The faulty system is then marked as broken.
While the system (call it host01.example.com) is in cloud01 and marked as broken, the query of the cloud for the date in which a schedule was active and included host01.example.com filters the host out. This is unexpected behavior as the output should reflect an accurate count and inventory for the query of past dates.
e.g.
[root@quads2 ]# quads --date '2026-02-27 08:00' --cloud-only --cloud cloud14
host02.example.com
host03.example.com
[root@quads2 ]# quads --host host01.example.com --ls-schedule
Default cloud: cloud01
Current cloud: cloud01
2080| start=2024-05-26T22:00, end=2024-10-13T22:00, cloud=cloud72
2751| start=2024-10-15T10:00, end=2025-02-04T09:31, cloud=cloud60
3785| start=2025-02-09T22:00, end=2025-02-23T22:00, cloud=cloud07
3940| start=2025-02-26T15:55, end=2025-07-27T22:00, cloud=cloud07
5597| start=2025-07-27T22:00, end=2025-11-25T22:00, cloud=cloud12
7497| start=2025-11-26T08:40, end=2026-01-25T22:00, cloud=cloud09
8347| start=2026-02-22T22:00, end=2026-02-23T12:38, cloud=cloud14
8416| start=2026-02-24T01:00, end=2026-02-27T12:51, cloud=cloud14
[root@quads2 ]# quads --ls-broken | grep host01.example.com
host01.example.com
In the above, it is verified that host01.example.com was in fact part of cloud14 but was filtered from the output when using the --cloud-only --cloud cloud14 arguments. It was filtered because host01.example.com is currently marked as faulty, but should have been included in the query of past (and current) schedules if asked to list all members of the allocation.