Skip to content

Honor fqdn StorageClass param when Anvil returns no data-portals - #66

Open
dfsweden wants to merge 1 commit into
masterfrom
fix/fqdn-no-dataportals
Open

Honor fqdn StorageClass param when Anvil returns no data-portals#66
dfsweden wants to merge 1 commit into
masterfrom
fix/fqdn-no-dataportals

Conversation

@dfsweden

@dfsweden dfsweden commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Summary

In a no-DSX deployment (Anvil-only; storage nodes registered as NODE/OTHER), GET /mgmt/v1.2/rest/data-portals/ returns []. In MountShareAtBestDataportal the address resolved from the StorageClass fqdn parameter (or the floating IP) was only ever consumed inside the per-data-portal mount loops. With an empty portals list those loops have zero iterations, so the resolved address is silently discarded and the driver fails with could not mount to any data-portals.

This broke file-backed PVC provisioning in any DSX-less environment — even when the user supplied fqdn:, which is the exact escape hatch that parameter is meant to be.

Fix

When GetDataPortals returns an empty list but an address was resolved, synthesize a single DataPortal from that address so the existing mount logic (showmount export discovery, NFS 4.2 → 3 fallback) runs against it. This mirrors the FQDN-first handling already present in EnsureRootExportMounted.

Scope

  • pkg/driver/utils.goMountShareAtBestDataportal (+20 lines)
  • CHANGELOG.md — one entry under [1.2.9] > Fixed

No behavior change when data-portals are present (the synthesis only triggers on an empty list). Also covers the floating-IP-but-no-portals case.

Testing

  • make compile succeeds (static binary, v1.2.9).
  • Driver unit tests pass (pre-existing unrelated TestAcquireVolumeLockTimeout failure aside).
  • Built image and confirmed the fix is present in the shipped binary.

In a no-DSX deployment (Anvil-only, storage nodes registered as
NODE/OTHER), GET /mgmt/v1.2/rest/data-portals/ returns []. In
MountShareAtBestDataportal the resolved fipaddr (from the StorageClass
`fqdn` parameter, or the floating IP) was only ever consumed inside the
per-portal mount loops. With an empty portals list those loops had zero
iterations, so the FQDN/IP the function resolved was discarded and the
driver failed with "could not mount to any data-portals" — breaking
file-backed PVC provisioning in any DSX-less environment, even when the
user supplied `fqdn:` as the intended escape hatch.

Synthesize a single DataPortal from the resolved fipaddr when the portal
list is empty, so the existing mount logic (showmount export discovery,
NFS 4.2 -> 3 fallback) runs against it. Mirrors the FQDN-first handling
already present in EnsureRootExportMounted.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ravi100k
ravi100k self-requested a review July 1, 2026 07:02
Comment thread pkg/driver/utils.go
// resolved fipaddr (from the FQDN or floating IP) would be silently thrown
// away. Synthesize a single portal from fipaddr so the existing mount logic
// (export discovery via showmount, NFS 4.2 -> 3 fallback) still runs.
if len(portals) == 0 && fipaddr != "" {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dfsweden
If no data-portals exist and no fqdn is provided, fipaddr remains empty, this synthetic portal block is skipped, and MountShareAtBestDataportal still returns "could not mount to any data-portals".
Should this fallback use GetAnvilPortal() when portals is empty and fipaddr is empty?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants