From 55fc8ddfbaec7f527ee8aeed67c9e86e4e498cea Mon Sep 17 00:00:00 2001
From: Teodor-Adrian Mihaescu <teodor-adrian.mihaescu@sap.com>
Date: Tue, 14 Jan 2025 11:31:55 +0100
Subject: [PATCH] Revert "docs: Update OTTL ADR with multi tranform/filter
 processor API (#1697)"

This reverts commit 8fc6e58ae9c60b256a02fcd858e42dbb709e9c25.
---
 ...-filter-support-for-telemetry-pipelines.md | 57 +++++--------------
 1 file changed, 14 insertions(+), 43 deletions(-)

diff --git a/docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md b/docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
index 0e82d9f61..4e4072279 100644
--- a/docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
+++ b/docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
@@ -12,7 +12,7 @@ In the default setup of metric and trace pipelines, users currently cannot filte
 
 ## Decision
 
-We will implement a consolidated solution in the OpenTelemetry Collector (OTel Collector) using Filter and Transform processors. These processors will use the OpenTelemetry Transformation and Transport Language (OTTL) to handle both filtering and transformation tasks. Users will be able to configure the processor as needed; only a subset of OTTL functions will be supported, focusing on the most common and impactful use cases.
+We will implement a consolidated solution in the OpenTelemetry Collector (OTel Collector) using a single Filter and Transform Processor. This processor will use the OpenTelemetry Transformation and Transport Language (OTTL) to handle both filtering and transformation tasks. Users will be able to configure the processor as needed; only a subset of OTTL functions will be supported, focusing on the most common and impactful use cases.
 
 MetricPipeline example configuration:
     
@@ -23,19 +23,15 @@ metadata:
   name: metricpipeline-sample
 spec:
   transform:
-    - conditions:
+    conditions:
       - type == METRIC_DATA_TYPE_SUM
-      - IsMatch(attributes["service.name"], "unknown")
-      statements:
+    statements:
       - set(description, "Sum")
-    - conditions:
-      - type == METRIC_DATA_TYPE_NONE
-      statements:
-      - convert_sum_to_gauge() where name == "system.processes.count" and (type == METRIC_DATA_TYPE_SUM or IsMatch(attributes["service.name"], "unknown")
   filter:
-      conditions:
-      - metric.name == "k8s.pod.phase" and value_int == 4
-      - metric.type == METRIC_DATA_TYPE_NONE
+    metric:
+        - type == METRIC_DATA_TYPE_NONE
+    datapoint:
+        - metric.name == "k8s.pod.phase" and value_int == 4
   input:
       istio:
         enabled: true
@@ -56,14 +52,11 @@ metadata:
   name: tracepipeline-sample
 spec:
   transform:
-    - conditions:
-      - IsMatch(span.resource.attributes["k8s.pod.name"], "my-pod-name.*")
-      statements:
-      - set(status.code, 1) where attributes["http.path"] == "/health"
+    statements:
+        - set(status.code, 1) where attributes["http.path"] == "/health"
   filter:
-      conditions:
-      - attributes["grpc"] == true
-      - IsMatch(span.resource.attributes["k8s.pod.name"], "my-pod-name.*")
+    span:
+      - IsMatch(resource.attributes["k8s.pod.name"], "my-pod-name.*")
   output:
     otlp:
       endpoint:
@@ -86,34 +79,12 @@ The recommended error mode is `ignore`, and this will be used as the default con
 
 The OTTL context will be embedded in the OTTL statements (in progress with [issue #29017](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/29017)) and will be available in the upcoming beta version. The solution will not implement the context as a configuration parameter.
 
-The proposed API uses no context configuration for filter processors. Instead, it only allows the configuration of condition expressions. The conditions are translated to the `datapoint` context for metrics and the `spanevent` context for traces. 
-Accessing higher-level context is still possible via OTTL expressions. For example, accessing the `metric` context from the `datapoint` context is possible via the expression `metric.*`, and accessing the `span` context from the `spanevent` context via the expression `span.*`.
-
-To ensure data consistency and sampling efficiency, the custom OTTL transformation and filtering processors will be near the end of the pipeline chain, before the exporters.
+To ensure data consistency and sampling efficiency, the custom OTTL transformation and filtering processor will be near the end of the pipeline chain, before the exporters.
 
 See the OTel configuration:
 
 ```yaml
 service:
-    processors:
-      transform/custom:
-        error_mode: ignore
-        metric_statements:
-        - conditions:
-          - type == METRIC_DATA_TYPE_SUM
-          - IsMatch(attributes["service.name"], "unknown")
-          statements:
-          - set(description, "Sum")
-        - conditions:
-          - type == METRIC_DATA_TYPE_NONE
-          statements:
-          - convert_sum_to_gauge() where name == "system.processes.count"
-      filter/custom:
-        error_mode: ignore
-        metrics:
-          datapoint:
-          - metric.name == "k8s.pod.phase" and value_int == 4
-          - metric.type == METRIC_DATA_TYPE_NONE
     pipelines:
         metrics/test-output:
             receivers:
@@ -126,8 +97,8 @@ service:
                 - transform/set-instrumentation-scope-kyma
                 - resource/insert-cluster-name
                 - resource/delete-skip-enrichment-attribute
-                - transform/custom
-                - filter/custom
+                - transform/custom-transform-processor
+                - filter/custom-filter-processor
                 - batch
             exporters:
                 - otlp/test