Skip to main content
Tensor9 BYOC adapts your application’s services into each customer’s environment. For selected service mappings, tuning tags let an origin API request supply a target-native choice that the origin API does not otherwise express. Start with the service catalog and select the origin service and customer’s target cloud. Tuning support is specific to that mapping and operation. A tag accepted by one service is not automatically supported by another.

​
Use the supported request carrier

Tuning tags use the form t9:tuning:<path>, where <path> names a supported target API field. Send the tag through the origin operation’s supported tag carrier, such as a create request’s tags. A create-time resource tag is not a per-request override for every subsequent operation. Updating a tag later changes the backend only when that service implements the corresponding update behavior. Review the service’s operation support before assuming a resource can be retuned in place. Keep the directive types separate: Acknowledging a difference does not restore missing behavior. Review its consequences for the application and the customer’s security requirements. Do not add acknowledgement tags solely to suppress a refusal.

​
Examples of target-native fields

In the IAM control-plane mapping to Google Cloud, t9:tuning:serviceAccount.displayName names the target service account’s display name. An IAM tag fragment looks like this:
The IAM implementation supports this tuning channel on role creation and supported role-tag updates. The tag changes descriptive metadata, not role permissions or trust policy. In the EKS control-plane mapping to GKE, the CreateNodegroup tag map can supply t9:tuning:config.machineType:
The target node pool uses the selected machine type while the origin description retains the application’s requested instanceTypes. Inspect the target pool to verify the effective choice. Check region availability, quota and workload fit, and do not assume an existing pool supports an in-place change. These are request fragments, not complete deployment examples. They illustrate implemented target-field behavior; check your release, selected mapping and operation before using them. Neither example establishes a performance improvement.

​
Test changes in your BYOC workflow

Use a test appliance matching the relevant customer form factor. Keep the baseline workload, adapter version, backend and existing settings. Change one supported choice and verify the resulting target resource before repeating the workload. Measure latency, throughput and errors under comparable conditions. A change that helps one target or workload may not help another. Validate each target you offer instead of assuming the result transfers across clouds. Keep the origin request or infrastructure change in your normal application review process. Its impact can extend beyond one customer deployment. Do not manually edit adapter configuration inside a customer appliance as a substitute for the supported BYOC release workflow.

​
Review tuning decisions

Use the service reference to distinguish default adaptation from a tuning override, then inspect the resulting test resource. Documentation is not a performance benchmark or evidence that a specific deployed request used a setting. For unexpected behavior, preserve the resource’s relevant tags and state and follow debugging service adapters.