address some review comments

Author: mozesl-nokia

docs/content/en/docs/2_concepts/functions.md

@@ -22,9 +22,10 @@ For details on how to declare and configure functions in the Kptfile pipeline, s
 
 ## Function Configuration
 
-Porch uses **FunctionConfig** custom resources to configure how functions execute. These configurations specify which executor type should handle specific function images and provide executor-specific settings.
+Porch uses **FunctionConfig** custom resources to configure how functions execute.
+These configurations determine which executor type should handle the given function images and provide executor-specific settings.
 
-Each FunctionConfig specifies:
+Each FunctionConfig defines:
 - **Image and prefixes**: The function image name and optional registry prefixes
 - **Executor configurations**: One or more executor types (pod, binary, or go) with associated settings
 - **Version-specific settings**: Different executors and configurations for different image tags
@@ -57,7 +58,8 @@ spec:
       - v0.4.5
 ```
 
-Both the function-runner and porch-server components include an embedded FunctionConfig reconciler that watches FunctionConfig resources and populates an internal cache. This cache determines which executor to use for each function invocation.
+Most Porch components include an embedded reconciler that watches FunctionConfig resources and populates the component's own internal cache.
+This cache determines which executor to use for each function invocation.
 
 ## Function Execution in Porch
 
@@ -78,9 +80,9 @@ Porch executes functions using multiple executor types, determined by FunctionCo
 - Only available for functions integrated as Go libraries
 - No container or process overhead
 
-Regardless of executor type, Porch passes the package's resources to kpt, which passes the resources on as a [ResourceList](https://github.com/kubernetes-sigs/kustomize/blob/master/cmd/config/docs/api-conventions/functions-spec.md#resourcelist) to each function in the pipeline in turn.
+Regardless of executor type, Porch passes the package's resources to [kpt](https://kpt.dev), which passes the resources on as a [ResourceList](https://github.com/kubernetes-sigs/kustomize/blob/master/cmd/config/docs/api-conventions/functions-spec.md#resourcelist) to each function in the pipeline in turn.
 kpt executes the functions sequentially in the order declared in the Kptfile pipeline and passes the function results back to Porch, which stores them in the PackageRevisionResources's `status.renderStatus` field.
-Execution is triggered automatically following creation or clone of a package revision, update of a package revision, and when a package revision is proposed.
+Pipeline execution is triggered automatically following creation or clone of a package revision, update of a package revision, and when a package revision is proposed.
 kpt passes the function results back to Porch and Porch stores them in the PackageRevisionResources's `status.renderStatus` field.
 
 ## When Functions Execute
@@ -137,7 +139,7 @@ enabling iterative development on incomplete packages.
 
 - Functions are standard KRM functions declared in the Kptfile pipeline (see [kpt functions docs](https://kpt.dev/book/04-using-functions/))
 - Function execution behavior is configured using FunctionConfig custom resources that specify executor types (pod, binary, or go)
-- Both function-runner and porch-server include FunctionConfig reconcilers that populate internal caches to determine which executor handles each function
+- Most Porch components include an embedded FunctionConfig reconciler that populates internal caches to determine which executor handles each function
 - Functions can execute via pod containers, local binaries, or in-process Go calls depending on configuration
 - Functions automatically execute during package rendering on Draft package revisions
 - Function results are stored in `status.renderStatus` of the PackageRevisionResources view of a package revision

docs/content/en/docs/5_architecture_and_components/function-runner/functionality/function-evaluation.md

@@ -589,43 +589,7 @@ The evaluation system employs several performance strategies.
 - Use executable evaluator for critical path
 - Monitor pod resource usage
 
-## FunctionConfig CRD
-
-The FunctionConfig CRD is the central configuration mechanism for function evaluation in both function-runner and porch-server.
-
-### CRD Structure
-
-**Core fields:**
-- **image**: Base image name (without prefix or tag)
-- **prefixes**: List of registry prefixes to match
-- **binaryExecutor**: Configuration for binary execution
-- **podExecutor**: Configuration for pod execution
-- **goExecutor**: Configuration for native Go execution (porch-server only)
-
-### Executor Types
-
-**Binary Executor:**
-- Maps specific image tags to local binary executables
-- **tags**: List of image tags to handle
-- **path**: Absolute or relative path to binary
-- Used by function-runner for fast local execution
-
-**Pod Executor:**
-- Runs functions in containers with configurable settings
-- **tags**: List of image tags to handle
-- **timeToLive**: Duration pods remain cached (default: 30m)
-- **templateOverrides**: Customize pod/container specifications
-- Used by function-runner for containerized execution
-
-**Go Executor:**
-- Executes functions as native Go calls
-- **tags**: List of image tags to handle
-- **id**: Registration ID for Go function (defaults to image name)
-- Used by porch-server for built-in functions
-
-### Configuration Reconciliation
-
-Both function-runner and porch-server embed a FunctionConfig reconciler:
+## Configuration Reconciliation
 
 **Reconciler behavior:**
 - Watches FunctionConfig CRDs in the function namespace
@@ -669,8 +633,8 @@ spec:
       - v0.4.5
 ```
 
-This configuration supports:
+This example configuration supports:
 - Binary execution for `set-namespace:v0.4.2`
 - Pod execution for `set-namespace:v0.4.1`
-- Native Go execution for `set-namespace:v0.4` and `v0.4.5` (porch-server only)
+- Native Go execution for `set-namespace:v0.4` and `v0.4.5`
 - Automatic prefix resolution for both qualified and unqualified images

docs/content/en/docs/5_architecture_and_components/function-runner/functionality/pod-lifecycle-management.md

@@ -128,13 +128,13 @@ The Pod Manager handles low-level Kubernetes operations for function pods and th
 
 **Image Metadata Operations** - Cache image digests and entrypoints, inspect container images to extract configuration, handle private registry authentication and TLS configuration, manage image pull secrets for function pods.
 
-**Template System** - Retrieve or create base pod and service templates from ServiceTemplate CRDs or inline defaults, track template versions to detect changes requiring pod replacement, patch templates with function-specific configuration and template overrides from FunctionConfig.
+**Template System** - Retrieve or create base pod and service templates from ServiceTemplate custom resources or inline defaults, track template versions to detect changes requiring pod replacement, patch templates with function-specific configuration and template overrides from FunctionConfig.
 
 ### Pod Template System
 
 The pod manager supports two template sources: ConfigMap-based templates for customization and inline templates as fallback defaults.
 
-The pod manager retrieves base pod and service templates from PodTemplate resources and ServiceTemplate CRs in the function execution namespace.
+The pod manager retrieves base pod and service templates from PodTemplate resources and ServiceTemplate resources in the function execution namespace.
 If these resources are not found, the pod manager creates them from embedded inline defaults.
 
 The template's `ResourceVersion` is used as the template version for tracking changes. When a template is updated, existing pods with old template versions are replaced on next use.
@@ -154,10 +154,6 @@ FunctionConfig resources can specify template overrides that customize the base
 
 These overrides are merged with the base template during pod creation, allowing function-specific customization without requiring separate templates for each function.
 
-**Legacy ConfigMap Approach:**
-
-Prior to the ServiceTemplate CRD implementation, pod and service templates were stored in ConfigMaps. This approach is deprecated. See [function-runner-pod-templates.md](../relevant_old_docs/function-runner-pod-templates.md) for historical reference.
- 
 ### Container Configuration
 
 The pod manager patches the function container in the template with function-specific configuration before creating the pod:

docs/content/en/docs/6_configuration_and_deployments/configurations/components/function-runner-config/_index.md

@@ -11,238 +11,6 @@ KPT functions and KRM functions are synonymous terms referring to the same conta
 
 The Function Runner executes KRM functions in a secure, isolated environment.
 
-## Function Configuration via FunctionConfig CRD
-
-FunctionConfig CRDs provide declarative configuration for KRM function execution. This is the primary method for configuring functions and replaces the previous ConfigMap-based approach.
-
-The function-runner includes an embedded reconciler that:
-- Watches FunctionConfig resources in the configured namespace
-- Maintains an internal cache of function configurations
-- Uses the cached configuration to determine executor selection and execution parameters
-
-### FunctionConfig Resource Structure
-
-```yaml
-apiVersion: config.porch.kpt.dev/v1alpha1
-kind: FunctionConfig
-metadata:
-  name: <function-name>
-  namespace: porch-fn-system
-spec:
-  # Base function image name (without registry prefix or tag)
-  image: <image-name>
-  
-  # Optional: List of registry prefixes that should be matched
-  # Empty string or omitted uses the default prefix
-  prefixes:
-    - ""
-    - ghcr.io/kptdev/krm-functions-catalog
-  
-  # Optional: Configuration for pod-based execution
-  podExecutor:
-    tags:
-      - v1.0.0
-    timeToLive: 30m
-    maxParallelExecutions: 2
-    preferredMaxQueueLength: 1
-    templateOverrides:
-      serviceAccountName: custom-sa
-      securityContext:
-        runAsUser: 1000
-      initContainer:
-        resources:
-          limits:
-            memory: "256Mi"
-      container:
-        resources:
-          limits:
-            memory: "512Mi"
-  
-  # Optional: Configuration for binary executable substitution
-  binaryExecutor:
-    tags:
-      - v1.0.0
-    path: /path/to/binary  # Absolute or relative to functions directory
-  
-  # Optional: Configuration for native Go execution
-  goExecutor:
-    tags:
-      - v1.0
-    id: custom-function-id  # Optional: defaults to spec.image
-```
-
-### Configuration Fields
-
-#### spec.image
-The base function image name without registry prefix or tag. This is matched against function references to determine which configuration to apply.
-
-#### spec.prefixes
-List of registry prefixes that should be matched for this function. An empty string matches the default registry prefix. If omitted, only exact image matches are considered.
-
-#### spec.podExecutor
-Configuration for running functions as Kubernetes pods:
-- **tags**: List of image tags this configuration applies to
-- **timeToLive**: Duration pods live before garbage collection (default: 30m)
-- **maxParallelExecutions**: Maximum number of concurrent pods for this function
-- **preferredMaxQueueLength**: Maximum waitlist length per pod
-- **templateOverrides**: Customizations to apply to the pod template
-
-#### spec.binaryExecutor
-Configuration for substituting function execution with a local binary:
-- **tags**: List of image tags that should use the binary
-- **path**: Absolute path or relative path to the functions directory
-
-#### spec.goExecutor
-Configuration for native Go function execution within the porch-server:
-- **tags**: List of image tags that should use native execution
-- **id**: Function identifier for registration (defaults to spec.image if omitted)
-
-### Template Overrides
-
-The `templateOverrides` structure allows customization of pod execution:
-
-```yaml
-templateOverrides:
-  # Service account for the function pod
-  serviceAccountName: function-sa
-  
-  # Pod security context
-  securityContext:
-    runAsUser: 1000
-    runAsGroup: 1000
-    fsGroup: 1000
-  
-  # Init container customizations
-  initContainer:
-    resources:
-      limits:
-        memory: "256Mi"
-        cpu: "500m"
-      requests:
-        memory: "128Mi"
-        cpu: "250m"
-    env:
-      - name: CUSTOM_VAR
-        value: "value"
-    envFrom:
-      - secretRef:
-          name: function-secret
-  
-  # Main container customizations
-  container:
-    resources:
-      limits:
-        memory: "512Mi"
-        cpu: "1000m"
-      requests:
-        memory: "256Mi"
-        cpu: "500m"
-    env:
-      - name: CUSTOM_VAR
-        value: "value"
-    envFrom:
-      - configMapRef:
-          name: function-config
-```
-
-### Example FunctionConfig Resources
-
-Basic pod executor configuration:
-
-```yaml
-apiVersion: config.porch.kpt.dev/v1alpha1
-kind: FunctionConfig
-metadata:
-  name: set-namespace
-  namespace: porch-fn-system
-spec:
-  image: set-namespace
-  prefixes:
-    - ""
-    - ghcr.io/kptdev/krm-functions-catalog
-  podExecutor:
-    tags:
-      - v0.4.1
-    timeToLive: 30m
-```
-
-Multi-executor configuration:
-
-```yaml
-apiVersion: config.porch.kpt.dev/v1alpha1
-kind: FunctionConfig
-metadata:
-  name: starlark
-  namespace: porch-fn-system
-spec:
-  image: starlark
-  prefixes:
-    - ""
-    - ghcr.io/kptdev/krm-functions-catalog
-  podExecutor:
-    tags:
-      - v0.4.3
-    timeToLive: 30m
-  binaryExecutor:
-    tags:
-      - v0.5.2
-    path: starlark
-  goExecutor:
-    id: starlark
-    tags:
-      - v0.5
-      - v0.5.5
-```
-
-Configuration with resource limits:
-
-```yaml
-apiVersion: config.porch.kpt.dev/v1alpha1
-kind: FunctionConfig
-metadata:
-  name: gatekeeper
-  namespace: porch-fn-system
-spec:
-  image: gatekeeper
-  prefixes:
-    - ""
-    - ghcr.io/kptdev/krm-functions-catalog
-  podExecutor:
-    tags:
-      - v0.2.1
-    timeToLive: 30m
-    maxParallelExecutions: 3
-    preferredMaxQueueLength: 2
-    templateOverrides:
-      container:
-        resources:
-          limits:
-            memory: "1Gi"
-            cpu: "1000m"
-          requests:
-            memory: "512Mi"
-            cpu: "500m"
-```
-
-### RBAC Requirements
-
-The function-runner requires permissions to watch FunctionConfig resources:
-
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: function-runner
-  namespace: porch-fn-system
-rules:
-  - apiGroups: ["config.porch.kpt.dev"]
-    resources: ["functionconfigs"]
-    verbs: ["get", "list", "watch"]
-  - apiGroups: ["config.porch.kpt.dev"]
-    resources: ["functionconfigs/status"]
-    verbs: ["get", "update", "patch"]
-```
-
 ## Configuration Options
 
 ### Command Line Arguments
@@ -437,5 +205,6 @@ spec:
 {{% alert title="Note" color="primary" %}}
 For advanced configuration options:
 - [Pod Templates]({{% relref "pod-templates" %}}) - Customize function pod specifications
+- [Function Configuration]({{% relref "function-configuration" %}}) - Customize function evaluation settings
 - [Private Registries]({{% relref "private-registries-config" %}}) - Configure private registry access
 {{% /alert %}}