Researched ClearML’s public REST API, configuration, user settings, and administrator-vault documentation.
Confirmed the machine flow: an access-key/secret-key pair authenticates auth.login through HTTP Basic; the returned token authenticates later API requests through Authorization: Bearer.
Cross-checked the published documentation against the open-source ClearML Server authentication schema, test client, and expiration defaults.
Assessed Executor’s OpenAPI authentication model. A manually generated bearer token can work as a static API-key-style header, but Executor does not perform ClearML’s login and refresh exchange. A thin refresh adapter is the safer production design.
Found that ClearML publishes HTML REST reference pages and models server services in a custom HOCON schema. An Executor integration will probably need a generated or small handwritten OpenAPI document.
Lessons Learned: Pitfalls
ClearML’s generated auth.login endpoint page labels the operation POST, while its REST overview and official curl examples use GET. Integration code should follow the working documented GET flow unless the target deployment explicitly configures another default method.
Token expiration and access/secret credential expiration are separate concepts. The 30-day default applies to bearer tokens; configurable credential expiration is a Hosted/Enterprise feature.
Lessons Learned: Improvements
If ClearML becomes a maintained infrastructure integration, add a durable SOP that records the deployment’s API base URL, chosen token lifetime, secret owner, rotation process, and whether a refresh adapter was deployed.
Keep the imported OpenAPI surface limited to required operations. This avoids translating the entire custom ClearML service schema before the integration proves useful.
