Title: GET /api/v2.0/system/version/ no longer includes “scale” in version string, breaking detection logic
Description: In TrueNAS SCALE Fangtooth 25.04, the API endpoint GET /api/v2.0/system/version/ returns:
"TrueNAS-25.04.0"
Previously, this version string included "scale" (e.g., "TrueNAS-SCALE-24.10.2.1"), which was used by external tools like democratic-csi driver to detect whether the instance is running TrueNAS SCALE.
This change breaks the getIsScale() method in democratic-csi code:
if (!(await httpApiClient.getIsScale())) {
throw new GrpcError(
grpc.status.FAILED_PRECONDITION,
driver is only availalbe with TrueNAS SCALE
);
}
...
async getIsScale() {
const systemVersion = await this.getSystemVersion();
if (systemVersion.v2 && systemVersion.v2.toLowerCase().includes("scale")) {
return true;
}
return false;
}
As a result, errors like this are thrown:
GrpcError: driver is only availalbe with TrueNAS SCALE
Expected behavior:
The version string should include "scale" again (e.g., "TrueNAS-SCALE-25.04.0") Impact:
Breaks CSI driver integrations that rely on version string parsing.
Affects automation and deployment tools. Environment:
But the product isn’t called “SCALE” any more, probably because all of the “scale” features have been de-scoped. It’s now “TrueNAS Community Edition” (or presumably “Enterprise Edition” if you have that license). This sounds like a bug in the democratic-csi integration, not in TrueNAS.
Right. We’ve never made any guarantees about how version strings are generated, so this is definitely not a TrueNAS bug. An example of a bug here would be if we returned something like “TrueNAS-???” or an incorrect version number like “25.4000” for “25.04.0”. That said, the democratic-csi is already making fixes on their end.
Nearly 6 months later and this is still broken in both democratic-csi and truenas-csp.
If you’re going for the “not our code, not our problem” approach, fair enough. There’s certainly a way to go, but these packages are pretty much the only way to use TrueNAS as a storage provider for kubernetes. Dropping a breaking change on them and just dusting your hands of any responsibility isn’t a great look in the enterprise space.
EDIT: For those googling the issue.
If you are hitting an error like this when using democratic-csi on TrueNAS 25.04 or greater:
GRPC error: rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 502 (Bad Gateway); malformed header: missing HTTP content-type
This thread and the replies within it are everything you need to know.
…and on exactly the same release. Why would you expect there to have been any change?
And why do you think it’s iX’ problem that these projects decided to rely on a string that wasn’t documented anywhere? And haven’t fixed their software in “nearly 6 months”?
The democratic-csi driver (available at GitHub - democratic-csi/democratic-csi: csi storage for container orchestration systems) allows users to integrate popular container solutions like Kubernetes, Nomad, Cloud Foundry, or Mesos into the TrueNAS CLI. The driver is sponsored by and officially supported by iXsystems for TrueNAS Enterprise Customers.
Well, well, well (“oh dear… anyway”, if I would dare a royal quote)
The product is no longer named SCALE, and iXsystems, which is no longer called iXsystems, may possibly deny that there was any guarantee that “the product” would be named SCALE.
So even the function name getIsScale() was based on a wrong assumption.
There will be no “correction” in Fangtooth, Goldeye, Halfmoon or whatever.
And there may be no guarantee there won’t be another breaking change…
It’s fully on democratic-csi to adapt its code to whatever whatever TrueNAS API might throw. Possibly with asking their sponsor about what may not break with the next release.
To parse a string does not seems to be an endeavour whose completion requires six months or more.
So if there’s still no fix, I see two possible explanations:
Sponsorship and official support “for TrueNAS Enterprise Customers” does not extend to the “Community Edition”.
Actually, there should be a relatively safe detection logic for getIsScale(): Figure out what CORE returns from the API call, and if the result does NOT match this pattern then it must be SCALE/CE. (With a fringe case for the ARM port…)
Actually, there should be a canonical way to do this, rather than each dev needing to figure something out on his own and hoping iX doesn’t break it in a future release.
