Ansible Guide

Ansible support is module-specific. Use a module only when its installed collection version exposes the endpoint and request behavior you need. This example scopes the test to amazon.aws.s3_object; it does not claim compatibility for the entire amazon.aws collection.

Start a local adapter

Use one service mapping before testing a larger playbook. This guide’s bounded fixture uses S3 backed by Google Cloud Storage:

Install or update the Tensor9 CLI

Install the customer CLI with Homebrew, then confirm the binary is available:

brew tap tensor9ine/tensor9
brew trust tensor9ine/tensor9
brew install tensor9
tensor9 --version

If tensor9 is already installed, run brew upgrade tensor9 instead of the install command.

Authenticate with Tensor9

A Tensor9 API key is required. Use the key issued during onboarding, or email [email protected] to request one for your organization. Do not share your account or key with another customer or organization.If your secret manager has already supplied T9_API_KEY, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run tensor9:

Bash
Zsh

set +x
IFS= read -r -s -p 'Tensor9 API key: ' T9_API_KEY
printf '\n'
export T9_API_KEY

set +x
IFS= read -r -s 'T9_API_KEY?Tensor9 API key: '
printf '\n'
export T9_API_KEY

Check that the variable is set without printing it, then verify your Tensor9 identity:

: "${T9_API_KEY:?Set T9_API_KEY before continuing}"
tensor9 whoami

Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. Keep shell tracing disabled while using the key. Do not paste the key into commands, shell profiles, source files, screenshots or support messages.See Install and Authenticate for the planned license lifecycle, entitlements and credential boundaries.

Inspect the S3 to Google Cloud Storage mapping

Ask Tensor9 to describe the exact directed service mapping used by this guide:

tensor9 explain \
  -origin aws::1.0.0::s3 \
  -target google::1.0.0::gcs \
  -fmt Human

Read the supported S3 operations and Google Cloud Storage limitations before starting the process. The mapping is directional: this command describes S3 requests adapted to Google Cloud Storage, not the reverse direction.

Prepare Google Cloud access

Authenticate with Google Cloud using its standard Application Default Credentials chain. The adapter uses that identity when it calls Google Cloud Storage.Use a dedicated test project and narrowly scoped credentials. Do not put credentials in the command line, source code, or screenshots.

Start the S3 service adapter

Run the S3 to Google Cloud Storage adapter as a foreground process:

tensor9 adapt svc run \
  --origin aws::1.0.0::s3 \
  --backend google::1.0.0::gcs

Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for local development mode. It calls your actual target-cloud services; it is separate from the in-memory emulator. Acquisition and license renewal require Tensor9 authentication. Keep the endpoint local to your test.

Copy the listening endpoint

When the command reports its listening endpoint, copy that exact value into a second terminal:

export T9_CLOUD_ADAPTER_ENDPOINT="<endpoint printed by tensor9>"

Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.

Run one bounded S3 request

Continue with this page’s client or tool instructions. Point only S3 at T9_CLOUD_ADAPTER_ENDPOINT, then perform one operation whose Google Cloud Storage effect you can verify independently.Check both sides: read the S3-shaped response and inspect the native object or bucket in Google Cloud Storage. A successful client response alone does not prove that the target state is correct.

Stop the local adapter

Return to the first terminal and press Control-C. Confirm the process exits before deleting the test object or bucket with Google Cloud’s native client.If the request failed, preserve the request ID, adapter endpoint, S3 operation name, Google Cloud request ID, and any x-t9-explain-* receipt headers before stopping the process.

Prerequisites

ansible-core and a pinned amazon.aws collection;
boto3 and Botocore versions supported by that collection;
an installed AWS-origin adapter endpoint;
an existing test bucket and an isolated key;
an origin-side test identity.

ansible-galaxy collection list amazon.aws
python -c 'import boto3, botocore; print(boto3.__version__, botocore.__version__)'

Write a bounded playbook

---
- name: Verify S3 through Cloud Adapter
  hosts: localhost
  gather_facts: false
  vars:
    adapter_endpoint: "{{ lookup('env', 'T9_CLOUD_ADAPTER_ENDPOINT') }}"
    test_bucket: "adapter-smoke-test"
    test_key: "ansible/cloud-adapter-smoke.txt"
    expected_body: "hello through Cloud Adapter\n"

  tasks:
    - name: Upload the smoke-test object
      amazon.aws.s3_object:
        mode: put
        bucket: "{{ test_bucket }}"
        object: "{{ test_key }}"
        content: "{{ expected_body }}"
        endpoint_url: "{{ adapter_endpoint }}"
        region: us-east-1
        profile: adapter-test
      register: first_put

    - name: Allocate an isolated download file
      ansible.builtin.tempfile:
        state: file
        suffix: .cloud-adapter-smoke
      register: downloaded

    - name: Download the object through Cloud Adapter
      amazon.aws.s3_object:
        mode: get
        bucket: "{{ test_bucket }}"
        object: "{{ test_key }}"
        dest: "{{ downloaded.path }}"
        endpoint_url: "{{ adapter_endpoint }}"
        region: us-east-1
        profile: adapter-test
      register: object_read

    - name: Read the downloaded bytes
      ansible.builtin.slurp:
        src: "{{ downloaded.path }}"
      register: downloaded_bytes

    - name: Prove the remote read returned the expected bytes
      ansible.builtin.assert:
        that:
          - object_read is succeeded
          - downloaded_bytes.content | b64decode == expected_body
        success_msg: "Cloud Adapter returned the expected object bytes"

Avoid printing the full registered result at high verbosity. It may contain endpoints, signed values, or response details that do not belong in shared logs.

Test idempotence

Run the playbook twice:

ansible-playbook adapter-smoke.yml --diff
ansible-playbook adapter-smoke.yml --diff

The second run should match the module’s documented idempotence behavior. If it reports a change every time, inspect which field differs and compare it with the target-specific fidelity table. Check mode is not proof of API compatibility because modules vary in how much remote state they read under --check.

Verify and clean up

Inspect the object in the native target service. Confirm bytes, content type, and translated resource identity. Then remove only the test object:

- name: Delete the smoke-test object
  amazon.aws.s3_object:
    mode: delobj
    bucket: "{{ test_bucket }}"
    object: "{{ test_key }}"
    endpoint_url: "{{ adapter_endpoint }}"
    region: us-east-1
    profile: adapter-test

Troubleshooting

Use -vv before -vvv; higher verbosity can expose sensitive request details. Separate collection validation, Python dependency failures, origin authentication, adapter translation, and target permissions. Reproduce the same operation with the AWS CLI guide when you need a smaller control. Check every operation against S3 service coverage.

Tensor9 Cloud Adapter

How It Works

Getting Started

Configuration

Deployment

Support

Amazon Web Services

Google Cloud

Microsoft Azure

Making Trade-offs

Tuning

Debugging

Testing

Guides

Reference

Start a local adapter

Prerequisites

Write a bounded playbook

Test idempotence

Verify and clean up

Troubleshooting

​Start a local adapter

​Prerequisites

​Write a bounded playbook

​Test idempotence

​Verify and clean up

​Troubleshooting

Start a local adapter

Prerequisites

Write a bounded playbook

Test idempotence

Verify and clean up

Troubleshooting