NAS-141362 / 25.10.4.1 / Fix handling field aliases in `APIVersionsAdapter` (#19108)
Not handling field aliases properly results in a series of tests
failing:
```
test_query_method[legacy_api_client=v25.10.3-query_method=audit.query] api2.test_legacy_api
middlewared.service_exception.ValidationErrors: [EINVAL] data.query_filters: Extra inputs are not permitted
[EINVAL] data.query_options: Extra inputs are not permitted
```
NAS-140265 / 26.0.0-RC.1 / Always render security_group ACG for FC targets (by bmeagherix) (#19112)
When an FC target's middleware initiator setting resolves to no WWPNs,
the mako previously dropped the GROUP security_group block entirely.
pyscstadmin's diff then has to issue del_group against the running
kernel, which SCST rejects with -EBUSY while FC sessions remain
attached. The result is /etc/scst.conf and the running configuration
silently diverging until a stop/start of the iscsi service.
Default the rendered initiator set to {'*'} when no WWPN restriction is
configured so the ACG is always present. Initiator updates then become
in-place INITIATOR add/remove operations rather than del_group; SCST
applies those cleanly.
----
Tested manually with FC.
Original PR: https://github.com/truenas/middleware/pull/19111
Co-authored-by: Brian M <brian.meagher at ixsystems.com>
Always render security_group ACG for FC targets
When an FC target's middleware initiator setting resolves to no WWPNs,
the mako previously dropped the GROUP security_group block entirely.
pyscstadmin's diff then has to issue del_group against the running
kernel, which SCST rejects with -EBUSY while FC sessions remain
attached. The result is /etc/scst.conf and the running configuration
silently diverging until a stop/start of the iscsi service.
Default the rendered initiator set to {'*'} when no WWPN restriction
is configured so the ACG is always present. Initiator updates then
become in-place INITIATOR add/remove operations rather than del_group;
SCST applies those cleanly.
(cherry picked from commit 879c8b0bd25be998c5c37e0ea9624bcf2b1d4451)
NAS-140265 / 27.0.0-BETA.1 / Always render security_group ACG for FC targets (#19111)
When an FC target's middleware initiator setting resolves to no WWPNs,
the mako previously dropped the GROUP security_group block entirely.
pyscstadmin's diff then has to issue del_group against the running
kernel, which SCST rejects with -EBUSY while FC sessions remain
attached. The result is /etc/scst.conf and the running configuration
silently diverging until a stop/start of the iscsi service.
Default the rendered initiator set to {'*'} when no WWPN restriction is
configured so the ACG is always present. Initiator updates then become
in-place INITIATOR add/remove operations rather than del_group; SCST
applies those cleanly.
Always render security_group ACG for FC targets
When an FC target's middleware initiator setting resolves to no WWPNs,
the mako previously dropped the GROUP security_group block entirely.
pyscstadmin's diff then has to issue del_group against the running
kernel, which SCST rejects with -EBUSY while FC sessions remain
attached. The result is /etc/scst.conf and the running configuration
silently diverging until a stop/start of the iscsi service.
Default the rendered initiator set to {'*'} when no WWPN restriction
is configured so the ACG is always present. Initiator updates then
become in-place INITIATOR add/remove operations rather than del_group;
SCST applies those cleanly.
NAS-141321 / 27.0.0-BETA.1 / Suspend VMs on snapshot by default (by creatorcary) (#19109)
## Summary
Change the default value of the per-VM `suspend_on_snapshot` setting
from `false` to `true`, so that newly created VMs — and existing ones
that never explicitly set it — are quiesced while a periodic snapshot of
their disk dataset is taken. This produces crash-consistent disk images
instead of snapshotting a running VM's storage live.
This restores the effective behavior that existed before #19053. Prior
to that PR, `vm.suspend_vms` suspended every running VM on its dataset's
snapshot regardless of the per-VM `suspend_on_snapshot` value — so in
practice running VMs were *always* suspended. #19053 fixed the flag so
it is actually honored. But because the field defaulted to `false`,
honoring it meant most VMs would no longer be suspended on snapshot — a
regression from the long-standing behavior. Flipping the default to
`true` keeps suspend-on-snapshot as the out-of-the-box behavior while
still letting users opt out per VM.
[12 lines not shown]
NAS-141321 / 26.0.0-RC.1 / Suspend VMs on snapshot by default (#19091)
Change the default value of the per-VM `suspend_on_snapshot` setting
from `false` to `true`, so that newly created VMs — and existing ones
that never explicitly set it — are quiesced while a periodic snapshot of
their disk dataset is taken. This produces crash-consistent disk images
instead of snapshotting a running VM's storage live.
This restores the effective behavior that existed before #19053. Prior
to that PR, `vm.suspend_vms` suspended every running VM on its dataset's
snapshot regardless of the per-VM `suspend_on_snapshot` value — so in
practice running VMs were *always* suspended. #19053 fixed the flag so
it is actually honored. But because the field defaulted to `false`,
honoring it meant most VMs would no longer be suspended on snapshot — a
regression from the long-standing behavior. Flipping the default to
`true` keeps suspend-on-snapshot as the out-of-the-box behavior while
still letting users opt out per VM.
On upgrade, every existing VM has `suspend_on_snapshot` set to `true`,
[5 lines not shown]
NAS-141321 / 26.0.0-RC.1 / Suspend VMs on snapshot by default (#19091)
## Summary
Change the default value of the per-VM `suspend_on_snapshot` setting
from `false` to `true`, so that newly created VMs — and existing ones
that never explicitly set it — are quiesced while a periodic snapshot of
their disk dataset is taken. This produces crash-consistent disk images
instead of snapshotting a running VM's storage live.
This restores the effective behavior that existed before #19053. Prior
to that PR, `vm.suspend_vms` suspended every running VM on its dataset's
snapshot regardless of the per-VM `suspend_on_snapshot` value — so in
practice running VMs were *always* suspended. #19053 fixed the flag so
it is actually honored. But because the field defaulted to `false`,
honoring it meant most VMs would no longer be suspended on snapshot — a
regression from the long-standing behavior. Flipping the default to
`true` keeps suspend-on-snapshot as the out-of-the-box behavior while
still letting users opt out per VM.
[6 lines not shown]
NAS-141166 / 26.0.0-RC.1 / Remove stale ARC graph names from reporting API (by Qubad786) (#19107)
## Problem
`reporting.get_data` accepted three graph names — `arcrate`,
`arcactualrate`, `arcresult` — whose backing plugin classes were deleted
during the ZFS netdata plugin rewrite. The Pydantic `Literal` and the
in-memory `__graphs` dict drifted out of sync, so passing any of them
crashed `netdata_get_data` with an uncaught `KeyError`.
## Solution
Removed the dead names from `GraphIdentifier.name`'s `Literal` and
docstring in both `v26_0_0/reporting.py` and `v27_0_0/reporting.py`.
Added a `ReportingNetdataGetDataArgs.from_previous` on each so legacy WS
clients walking the adapter chain get the dead entries silently filtered
instead of a hard rejection at the final v27 boundary. Hardened the
dispatch site in `plugins/reporting/graphs.py` to raise
`CallError(ENOENT)` for any unknown name — mirroring what
[5 lines not shown]
