genegr opened a new pull request, #13060: URL: https://github.com/apache/cloudstack/pull/13060
The FlashArray adapter previously always made an initial call to the deprecated Purity REST 1.x session endpoint using a username and password to obtain a long-lived api_token, then exchanged that token for the REST 2.x x-auth-token session key. Purity 1.x is being removed from the array, so this path has an expiration date, and storing the username and password as pool details is not what the Purity documentation recommends. Accept a pre-minted api_token in the pool details (ProviderAdapter.API_TOKEN_KEY, already reserved in the base interface) and go straight to the REST 2.x /login endpoint. The api_token is long-lived and is created on the array via the Purity GUI (Users -> API Tokens) or CLI (pureadmin create --api-token). If api_token is not set, fall back to the legacy username/password flow and emit a deprecation warning so existing deployments keep working during the transition. The fallback path will be removed in a later release. While here, resolve the API version dynamically by calling the unauthenticated GET /api/api_version endpoint the first time a login happens on a pool, unless the operator pinned a specific version via API_VERSION. This makes the adapter pick up newer Purity releases automatically instead of being stuck on the hard-coded 2.23 default. ### Description The FlashArray adapter currently performs two calls to log in: a POST to the deprecated Purity **REST 1.x** `auth/apitoken` endpoint with username/password to obtain a long-lived `api_token`, then a POST to `/api/<ver>/login` with `api-token:` header to get the session `x-auth-token`. Pure Storage is phasing out REST 1.x, and storing username/password as pool details is not the recommended pattern. This PR: - Accepts a pre-minted long-lived `api_token` as a pool detail (`ProviderAdapter.API_TOKEN_KEY`, already reserved in the base interface). When present, the adapter skips the 1.x call entirely and goes straight to `POST /api/<ver>/login` with `api-token:` header. - Falls back to the legacy username/password flow when `api_token` is not set, logging a deprecation warning. No existing deployments break; removal of the fallback can happen in a later release. - Discovers the latest supported REST API version by calling the unauthenticated `GET /api/api_version` on first login (unless an explicit `api_version` pool detail pins it). Replaces the hardcoded `2.23` default, so the adapter tracks newer Purity releases automatically. ### Types of changes - [x] Enhancement (non-breaking change which adds functionality) ### How Has This Been Tested? Validated on a 4.23-SNAPSHOT lab against a Purity 6.7.7 FlashArray: - Added `details[api_token]=<long-lived-token>` to an existing pool and restarted mgmt → adapter resumes without the deprecation warning, capacity polling and volume create continue working. - Removed the api_token detail → adapter logs the deprecation warning and falls back to u/p against `/api/1.19/auth/apitoken`, still working. - `/api/api_version` discovery resolves to `2.36` on Purity 6.7.7 without manual configuration. ### How to Get an API Token on the Array Purity GUI: *Settings → Users → <user> → API Tokens → Create API Token*. CLI: `ssh pureuser@<array>; pureadmin create --api-token <user>`. -- 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]
