A10 Thunder ADC Service Discovery

Overview

The A10 Discovery Service automates the discovery and registration of services hosted on an A10 Thunder Application Delivery Controller (ADC). It connects to the A10 device using the aXAPI v3 API, inventories all configured SLB Virtual Servers (VS) and their associated ports, and syncs them into the platform's service registry.

This component solves the problem of manually tracking and registering services exposed through an A10 load balancer. By treating each port on a Virtual Server as a distinct discoverable service, it provides a granular view of the frontend endpoints available for API traffic.

The discovery process is initiated by invoking the runDiscovery method with a target A10 instance identifier. It reads credentials from the s2r_lb_connector_credentials table, communicates with the A10 aXAPI, and then upserts the discovered service information into the s2r_discovered_service database table.

How it Works

The discovery process follows a precise sequence of API calls and data transformations to translate A10 Thunder ADC configuration into platform service entries.

Discovery Flow

The service executes the following steps for each discovery run:

1. Load Credentials: Retrieves the host, port, username, and password for the target A10 instance from the s2r_lb_connector_credentials store.
2. Authenticate: Establishes a session with the A10 Thunder ADC by sending a POST request to the /axapi/v3/auth endpoint. A successful authentication returns a signature (token) used for subsequent requests.
3. List Virtual Servers: Fetches a list of all configured SLB Virtual Servers by making a GET request to /axapi/v3/slb/virtual-server.
4. Enumerate Ports and Service Groups: For each Virtual Server, the service performs a series of nested queries: a. It fetches all configured ports for the VS via GET /axapi/v3/slb/virtual-server/{name}/port. b. For each port, it checks for an associated service-group. c. If a service-group is present, it fetches the group's details, including its member list, via GET /axapi/v3/slb/service-group/{name}.
5. Assemble Service Data: The raw JSON responses for the Virtual Server, its port, and the service group (if any) are collected. This data is mapped to a standardized service model.
6. Log Off: The service makes a best-effort attempt to terminate the aXAPI session via POST /axapi/v3/logoff. This step is not critical to the success of the discovery.
7. Persist Results: The collected service data is written to the s2r_discovered_service database table. New services are inserted, existing ones are updated, and any services previously seen but not found in the current run are marked as inactive.

The following diagram illustrates the interaction between the platform and the A10 Thunder ADC during a discovery run.

sequenceDiagram
    participant Platform
    participant A10 Thunder ADC
    participant Platform Database

    Platform->>Platform: runDiscovery(gatewayType, instanceName)
    Platform->>Platform Database: Load credentials for instance
    Platform->>A10 Thunder ADC: POST /axapi/v3/auth
    A10 Thunder ADC-->>Platform: Auth Signature
    Platform->>A10 Thunder ADC: GET /axapi/v3/slb/virtual-server
    A10 Thunder ADC-->>Platform: List of Virtual Servers
    loop For each Virtual Server
        Platform->>A10 Thunder ADC: GET /slb/virtual-server/{vs-name}/port
        A10 Thunder ADC-->>Platform: List of ports
        loop For each Port
            alt Port has a Service Group
                Platform->>A10 Thunder ADC: GET /slb/service-group/{sg-name}
                A10 Thunder ADC-->>Platform: Service Group details
            end
            Platform->>Platform: Assemble discovered service record
        end
    end
    Platform->>A10 Thunder ADC: POST /axapi/v3/logoff (best-effort)
    Platform->>Platform Database: UPSERT records into s2r_discovered_service
    Platform->>Platform Database: Mark stale records as inactive
    Platform-->>Platform: Return DiscoveryResult

Data Mapping

Each port on a Virtual Server is treated as a unique, discoverable service. The mapping from A10 configuration objects to the platform's service model is as follows:

API Reference

The service exposes a single public method to initiate a discovery pass.

runDiscovery

Triggers a full discovery and persistence cycle for a specified A10 Thunder ADC instance.

DiscoveryResult runDiscovery(String gatewayType, String instanceName)

Parameters

Returns

An object of type DiscoveryResult containing statistics about the run:

Throws

• LbConnectorCredentialService.NotFoundException: If credentials for the specified gatewayType and instanceName are not found in the s2r_lb_connector_credentials table.

Configuration

The A10 Discovery Service relies on credentials stored in the s2r_lb_connector_credentials table. Each A10 instance must have a corresponding entry with the following details.

Troubleshooting

The discovery process logs errors with specific codes to aid in diagnostics.

See Also

• A10 aXAPI v3 Authentication Documentation
• A10 aXAPI v3 SLB Virtual Server Documentation
• Load Balancer Connector Credentials management.

All SOAP-to-REST docs