jmsperu commented on issue #140: URL: https://github.com/apache/cloudstack-go/issues/140#issuecomment-4757411246
Looked into this. The root cause is in the generator: when a `list<X>` API exposes both `name` and `keyword` string params, the `Get<X>ID`/`Get<X>ByName` emitter now prefers `name` (generate/generate.go — `if p.Name == "name" ... return "name"` takes precedence over the `keyword` branch). `listNetworks` has both, so post-2.19.0 it searches by `name`, which CloudStack < 4.22 rejects. Two ways forward: **A. Fallback (version-agnostic, smallest change).** Search by `name`; if the call fails with an unknown-parameter error (what < 4.22 returns for `name`), retry with `keyword`. No version logic, works everywhere; the only cost is one extra call on the legacy path. **B. Version-aware (addresses the blocker @hrak hit).** A `client.Version()` is actually feasible today — `listCapabilities` returns it, and the SDK already models it: `Capability.Cloudstackversion` (ConfigurationService.go). A small lazily-cached helper (call `ListCapabilities` once, parse `cloudstackversion`, memoize on the client) gives a `CloudStackVersion()` primitive, after which `GetNetworkID` can branch `name` (>= 4.22) vs `keyword` (older). This is reusable well beyond networks, since the generator’s `name`-preference change affects every `Get<X>ID` whose list API gained a `name` param. My suggestion: ship **A** as the immediate backward-compat fix, and add **B** as the general primitive (it’s broadly useful and is the clean long-term answer). Happy to put up a PR for either/both once a maintainer signals a preference — I have a 4.22 environment to test against. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
