AWS solutions documentation change
Summary
Updated documentation for custom transformer usage in migration workflows. Added ConfigMap-based approach for workflow runs, clarified manual run procedures, restructured configuration options table, and deprecated shared volume usage.
Security assessment
The changes focus on operational improvements and configuration management updates. No security vulnerabilities, incidents, or weaknesses are addressed. The removal of shared volume usage (/shared-logs-output) could indirectly improve security by avoiding persistent storage of sensitive scripts, but this isn't explicitly stated as a security measure.
Diff
diff --git a/solutions/latest/migration-assistant-for-amazon-opensearch-service/tft-custom-transformer.md b/solutions/latest/migration-assistant-for-amazon-opensearch-service/tft-custom-transformer.md index db8280ab2..b0e47913a 100644 --- a//solutions/latest/migration-assistant-for-amazon-opensearch-service/tft-custom-transformer.md +++ b//solutions/latest/migration-assistant-for-amazon-opensearch-service/tft-custom-transformer.md @@ -11 +11 @@ Ways to supply the transformer configuration -When a field type is not covered by the built-in transformations, you can supply a custom JavaScript transformer that rewrites mappings as metadata is migrated. The transformer is a JavaScript function that receives each metadata document and returns the modified document. You register it with a transformer descriptor and pass that descriptor to the metadata migration phase. +When a field type is not covered by the built-in transformations, you can supply a custom JavaScript transformer that rewrites mappings as metadata is migrated. The transformer is a JavaScript function that receives each metadata document and returns the modified document. For workflow runs, reference the script with `metadataTransforms`; for one-off manual runs, pass a raw transformer descriptor to the metadata migration command. @@ -13 +13 @@ When a field type is not covered by the built-in transformations, you can supply -The following procedure runs from the Migration Console pod. It writes the transformer script and descriptor to the shared logs volume so they persist for the migration, then runs the metadata migration with the descriptor applied. +The following procedure runs from the Migration Console pod. It writes the transformer script to a temporary file so you can package it in a ConfigMap for the workflow or reference it from a raw descriptor for a manual metadata run. @@ -21 +21 @@ The following procedure runs from the Migration Console pod. It writes the trans - cat > /shared-logs-output/field-type-converter.js << 'SCRIPT' + cat > /tmp/field-type-converter.js << 'SCRIPT' @@ -71 +71,37 @@ The following procedure runs from the Migration Console pod. It writes the trans - 3. Create a transformer descriptor that points to the script. The `JsonJSTransformerProvider` loads your JavaScript from `initializationScriptFile`, and `bindingsObject` passes optional context to the script (use `"{}"` when you have no bindings): + 3. For a workflow run, create a ConfigMap from the transformer file: + + kubectl create configmap metadata-transforms -n ma \ + --from-file=field-type-converter.js=/tmp/field-type-converter.js + + 4. Add the transform under `metadataMigrationConfig.metadataTransforms` in the workflow configuration: + + { + "snapshotMigrationConfigs": [ + { + "fromSource": "source", + "toTarget": "target", + "perSnapshotConfig": { + "snap1": [ + { + "metadataMigrationConfig": { + "metadataTransforms": [ + { + "entryPoint": { + "javascriptFile": { + "configMap": "metadata-transforms", + "path": "field-type-converter.js" + } + } + } + ] + } + } + ] + } + } + ] + } + +The ConfigMap must already exist in the migration namespace, and `path` is the ConfigMap key that contains the transform file. For image-backed transforms, use `{"image": "example.com/transforms@sha256:…", "path": "metadata.js"}` instead. For the full workflow transform schema, including inline scripts, Python, named providers, and context values, see [Workflow transform pipeline model](./data-transforms.html#transform-pipeline-model). + + 5. For a manual metadata run, create a transformer descriptor that points to the script. The `JsonJSTransformerProvider` loads your JavaScript from `initializationScriptFile`, and `bindingsObject` passes optional context to the script (use `"{}"` when you have no bindings): @@ -76 +112 @@ The following procedure runs from the Migration Console pod. It writes the trans - "initializationScriptFile": "/shared-logs-output/field-type-converter.js", + "initializationScriptFile": "/tmp/field-type-converter.js", @@ -82 +118 @@ The following procedure runs from the Migration Console pod. It writes the trans -Save this descriptor to a file on the shared volume, for example `/shared-logs-output/transformation.json`. +Save this descriptor to a file on the Migration Console pod, for example `/tmp/transformation.json`. @@ -84 +120 @@ Save this descriptor to a file on the shared volume, for example `/shared-logs-o - 4. Run metadata migration with the descriptor applied: + 6. Run metadata migration with the descriptor applied: @@ -86 +122 @@ Save this descriptor to a file on the shared volume, for example `/shared-logs-o - console metadata migrate --transformer-config-file /shared-logs-output/transformation.json + console metadata migrate --transformer-config-file /tmp/transformation.json @@ -93 +129 @@ Save this descriptor to a file on the shared volume, for example `/shared-logs-o -The workflow accepts the same transformer descriptor through three configuration fields, so you can choose whichever fits how you manage configuration: +The workflow accepts a transform pipeline and the older raw descriptor fields, so you can choose whichever fits how you manage configuration: @@ -97,3 +133,4 @@ Field | Use it when -`transformerConfig` | You want to embed the descriptor JSON inline in the workflow configuration. -`transformerConfigBase64` | You want to pass the descriptor as a Base64-encoded string — useful for avoiding quoting or escaping problems when the JSON is set through automation. -`transformerConfigFile` | You want to reference a descriptor file on the shared volume rather than inline the JSON. This is the workflow-configuration equivalent of the `console metadata migrate --transformer-config-file` flag shown in the preceding procedure. +`metadataTransforms` | You want the workflow to mount JavaScript or Python transform files from a ConfigMap or OCI image and generate the metadata transformer configuration. This is the preferred workflow form. +`transformerConfig` | You want to embed the raw descriptor JSON inline in the workflow configuration. +`transformerConfigBase64` | You want to pass the raw descriptor as a Base64-encoded string — useful for avoiding quoting or escaping problems when the JSON is set through automation. +`transformerConfigFile` | You want to reference a descriptor file that is already mounted into the metadata migration container rather than inline the JSON. This is the workflow-configuration equivalent of the `console metadata migrate --transformer-config-file` flag shown in the preceding procedure, but the workflow does not mount Migration Console files into metadata pods by default. @@ -103 +140 @@ Field | Use it when -Supply the descriptor through exactly one of these fields. When you run `console metadata migrate` interactively, use the `--transformer-config-file` flag; when you declare the transformer in the migration workflow configuration, set `transformerConfig`, `transformerConfigBase64`, or `transformerConfigFile` on the metadata migration configuration. Load the version-matched sample with `workflow configure sample --load` and edit it with `workflow configure edit` to confirm the exact placement for your installed release. +Use either `metadataTransforms` or one raw configuration field, not both. When you run `console metadata migrate` interactively, use the `--transformer-config-file` flag; when you declare the transformer in the migration workflow configuration, set `metadataTransforms`, `transformerConfig`, `transformerConfigBase64`, or `transformerConfigFile` on the metadata migration configuration. Load the version-matched sample with `workflow configure sample --load` and edit it with `workflow configure edit` to confirm the exact placement for your installed release.