The current IBM OpenStack sensor (com.instana.plugin.ibmopenstack) has several hardcoded defaults that prevent it from working with non-standard or self-hosted OpenStack deployments. The sensor appears to have been built primarily for Red Hat OpenStack Platform deployments and does not account for differences in Canonical/Ubuntu OpenStack (including MicroStack, Sunbeam, and Charmed OpenStack) or other OpenStack distributions where Keystone paths, protocols, and authentication scoping differ.
The following configuration options should be added to the sensor's remote configuration block:
1. API Path (api_path): The Keystone authentication endpoint path is currently hardcoded to /v3/auth/tokens. Many OpenStack deployments — especially Canonical OpenStack using Sunbeam or Charmed operators — use a reverse proxy or custom path prefix (e.g. /openstack-keystone/v3/auth/tokens). The sensor should allow configuring the full Keystone API base path.
2. Protocol (protocol): The sensor currently only supports HTTPS. When the Instana agent is deployed directly inside the OpenStack cluster — which is a common and recommended deployment pattern for infrastructure monitoring — the Keystone and Nova API endpoints are typically accessed over plain HTTP on internal service networks. This is standard behavior in both Canonical and Red Hat OpenStack deployments, where internal API endpoints use HTTP while only public-facing endpoints are exposed over HTTPS. Additionally, lab, development, and staging environments frequently run without TLS entirely. A configurable protocol option (http or https) should be supported to cover both internal and external monitoring scenarios.
3. Certificate Verification (verify_certs): There is no option to disable TLS certificate verification. Self-signed certificates are common in private cloud and lab environments, and are the default in many Canonical OpenStack deployments. A boolean flag to skip certificate validation should be added, similar to the existing com.instana.agent.validation.validateCerts setting but at the sensor level.
4. Domain (domain): Keystone v3 requires domain-scoped authentication. The sensor currently does not expose a domain configuration parameter. Without it, authentication fails with HTTP 401 on deployments where the domain is required for token scoping. Both Red Hat and Canonical OpenStack use domain-scoped auth in Keystone v3. A domain field (defaulting to "Default") should be added.
5. Canonical/Ubuntu OpenStack Compatibility: The sensor should be tested and validated against Canonical OpenStack distributions (Charmed OpenStack, Sunbeam, and MicroStack) in addition to Red Hat OpenStack Platform. Canonical is one of the largest OpenStack distributors, and its deployments often differ in service endpoint paths, default TLS configuration, and authentication structure compared to Red Hat.
Proposed configuration example:
com.instana.plugin.ibmopenstack:
enabled: true
remote:
- host: 'openstack.example.com'
port: '443'
protocol: 'https'
api_path: '/openstack-keystone/v3'
user: 'admin'
password: 'secret'
project: 'admin'
domain: 'Default'
verify_certs: false
poll_rate: 15
Without these options, the sensor cannot authenticate against many real-world OpenStack deployments — particularly Canonical-based ones — causing repeated HTTP 401 failures, automatic sensor removal, and a continuous install/fail/remove loop in the agent logs.
