Add priority class support for Velero server and node-agent

- Add --server-priority-class-name and --node-agent-priority-class-name flags to velero install command
- Configure data mover pods (PVB/PVR/DataUpload/DataDownload) to use priority class from node-agent-configmap
- Update e2e tests to include PriorityClass label for testing
- Move priority class design document to Implemented folder
- Add changelog entry for velero-io#8883

🤖 Generated with [Claude Code](https://claude.ai/code)

Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>

Add support for ConfigMap options in Velero server installation

Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>

Implement centralized ConfigMap watching for node-agent controllers

This change introduces a centralized ConfigMap watching mechanism to eliminate
redundant ConfigMap watchers across controllers. Previously, each controller
(PodVolumeBackup, PodVolumeRestore, DataUpload, DataDownload) independently
watched the same ConfigMap, leading to inefficiency.

Key changes:
- Add ConfigProvider interface for centralized configuration management
- Implement nodeAgentConfigProvider with single ConfigMap watcher
- Update all controllers to use ConfigProvider instead of direct watching
- Add comprehensive unit tests for ConfigProvider implementation
- Add enhanced MockConfigProvider for testing
- Add E2E test for validating centralized watching behavior
- Remove redundant ConfigMap watching code from controllers

Benefits:
- Single source of truth for ConfigMap watching
- Reduced resource usage with one watcher instead of four
- Consistent configuration updates across all controllers
- Improved testability with centralized mocking
- Better separation of concerns

🤖 Generated with [Claude Code](https://claude.ai/code)

Fix ConfigProvider tests for empty ConfigMap name and informer behavior

- Handle empty ConfigMap name gracefully in NewNodeAgentConfigProvider
- Skip informer start when ConfigMap name is empty
- Update test expectations to handle informer Add events on startup
- Ensure tests pass with correct behavior for edge cases

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: kaovilai

changelogs/unreleased/8883-kaovilai

@@ -0,0 +1 @@
+Implement PriorityClass Support

…gn/priority-class-name-support_design.md …ed/priority-class-name-support_design.mddesign/priority-class-name-support_design.md renamed to design/Implemented/priority-class-name-support_design.md design/priority-class-name-support_design.md renamed to design/Implemented/priority-class-name-support_design.md

@@ -1,28 +1,34 @@
 # PriorityClass Support Design Proposal
 
 ## Abstract
+
 This design document outlines the implementation of priority class name support for Velero components, including the Velero server deployment, node agent daemonset, and maintenance jobs. This feature allows users to specify a priority class name for Velero components, which can be used to influence the scheduling and eviction behavior of these components.
 
 ## Background
+
 Kubernetes allows users to define priority classes, which can be used to influence the scheduling and eviction behavior of pods. Priority classes are defined as cluster-wide resources, and pods can reference them by name. When a pod is created, the priority admission controller uses the priority class name to populate the priority value for the pod. The scheduler then uses this priority value to determine the order in which pods are scheduled.
 
 Currently, Velero does not provide a way for users to specify a priority class name for its components. This can be problematic in clusters where resource contention is high, as Velero components may be evicted or not scheduled in a timely manner, potentially impacting backup and restore operations.
 
 ## Goals
+
 - Add support for specifying priority class names for Velero components
 - Update the Velero CLI to accept priority class name parameters for different components
 - Update the Velero deployment, node agent daemonset, maintenance jobs, and data mover pods to use the specified priority class names
 
 ## Non Goals
+
 - Creating or managing priority classes
 - Automatically determining the appropriate priority class for Velero components
 
 ## High-Level Design
+
 The implementation will add new fields to the Velero options struct to store the priority class names for the server deployment and node agent daemonset. The Velero CLI will be updated to accept new flags for these components. For data mover pods and maintenance jobs, priority class names will be configured through existing ConfigMap mechanisms (`node-agent-configmap` for data movers and `repo-maintenance-job-configmap` for maintenance jobs). The Velero deployment, node agent daemonset, maintenance jobs, and data mover pods will be updated to use their respective priority class names.
 
 ## Detailed Design
 
 ### CLI Changes
+
 New flags will be added to the `velero install` command to specify priority class names for different components:
 
 ```go
@@ -44,6 +50,7 @@ flags.StringVar(
 Note: Priority class names for data mover pods and maintenance jobs will be configured through their respective ConfigMaps (`--node-agent-configmap` for data movers and `--repo-maintenance-job-configmap` for maintenance jobs).
 
 ### Velero Options Changes
+
 The `VeleroOptions` struct in `pkg/install/resources.go` will be updated to include new fields for priority class names:
 
 ```go
@@ -55,6 +62,7 @@ type VeleroOptions struct {
 ```
 
 ### Deployment Changes
+
 The `podTemplateConfig` struct in `pkg/install/deployment.go` will be updated to include a new field for the priority class name:
 
 ```go
@@ -93,6 +101,7 @@ deployment := &appsv1api.Deployment{
 ```
 
 ### DaemonSet Changes
+
 The `DaemonSet` function will use the priority class name passed via the podTemplateConfig (from the CLI flag):
 
 ```go
@@ -112,6 +121,7 @@ daemonSet := &appsv1api.DaemonSet{
 ```
 
 ### Maintenance Job Changes
+
 The `JobConfigs` struct in `pkg/repository/maintenance/maintenance.go` will be updated to include a field for the priority class name:
 
 ```go
@@ -187,6 +197,7 @@ velero install --provider aws \
 The ConfigMap can be updated after installation to change the priority class for future maintenance jobs. Note that only the "global" configuration is used for priority class - all maintenance jobs will use the same priority class regardless of which repository they are maintaining.
 
 ### Node Agent ConfigMap Changes
+
 We'll update the `Configs` struct in `pkg/nodeagent/node_agent.go` to include a field for the priority class name in the node-agent-configmap:
 
 ```go
@@ -352,6 +363,7 @@ if priorityClassName != "" {
 ```
 
 These validation and logging features will help administrators:
+
 - Identify configuration issues early (validation warnings)
 - Troubleshoot priority class application issues
 - Verify that priority classes are being applied as expected
@@ -371,6 +383,7 @@ The `ValidatePriorityClass` function should be called at the following points:
    - Before creating maintenance jobs
 
 Example usage:
+
 ```go
 // During velero install
 if o.ServerPriorityClassName != "" {
@@ -519,10 +532,10 @@ velero install \
 
 When configuring priority classes for Velero components, consider the following hierarchy based on component criticality:
 
-1. **Velero Server (Highest Priority)**: 
+1. **Velero Server (Highest Priority)**:
    - Example: `velero-critical` with value 100
    - Rationale: The server must remain running to coordinate backup/restore operations
-   
+
 2. **Node Agent DaemonSet (Medium Priority)**:
    - Example: `velero-standard` with value 50
    - Rationale: Node agents need to be available on nodes but are less critical than the server
@@ -544,35 +557,64 @@ This approach has several advantages:
 
 The priority class name for data mover pods will be determined by checking the node-agent-configmap. This approach provides a centralized way to configure priority class names for all data mover pods. The same approach will be used for PVB (PodVolumeBackup) and PVR (PodVolumeRestore) pods, which will also retrieve their priority class name from the node-agent-configmap.
 
-For PVB and PVR pods specifically, the controllers will need to be updated to retrieve the priority class name from the node-agent-configmap and pass it to the pod creation functions. For example, in the PodVolumeBackup controller:
+For PVB and PVR pods specifically, the implementation follows this approach:
+
+1. **Controller Initialization**: Both PodVolumeBackup and PodVolumeRestore controllers are updated to accept nodeAgentConfigMap and namespace parameters. During initialization, they retrieve the priority class name from the node-agent-configmap:
 
 ```go
-// In pkg/controller/pod_volume_backup_controller.go
-priorityClassName, _ := kube.GetDataMoverPriorityClassName(ctx, namespace, kubeClient, configMapName)
+// In NewPodVolumeBackupReconciler and NewPodVolumeRestoreReconciler
+dataMovePriorityClass := ""
+if nodeAgentConfigMap != "" {
+    ctx, cancel := context.WithTimeout(context.Background(), time.Second*30)
+    defer cancel()
+    priorityClass, err := kube.GetDataMoverPriorityClassName(ctx, namespace, kubeClient, nodeAgentConfigMap)
+    if err != nil {
+        log.WithError(err).Warn("Failed to get priority class name from node-agent-configmap, using empty value")
+    } else {
+        dataMovePriorityClass = priorityClass
+        if priorityClass != "" {
+            log.WithField("priorityClassName", priorityClass).Info("Using priority class for data mover pods")
+        }
+    }
+}
+```
 
-// Add priorityClassName to the pod spec
-pod := &corev1api.Pod{
+2. **PodVolumeExposeParam Update**: The PodVolumeExposeParam struct in pkg/exposer/pod_volume.go is updated to include a PriorityClassName field:
+
+```go
+type PodVolumeExposeParam struct {
     // ... existing fields ...
-    Spec: corev1api.PodSpec{
-        // ... existing fields ...
-        PriorityClassName: priorityClassName,
-    },
+    // PriorityClassName is the priority class name for the data mover pod
+    PriorityClassName string
 }
 ```
 
-Similarly, in the PodVolumeRestore controller:
+3. **Pod Creation**: The createHostingPod function in pkg/exposer/pod_volume.go is updated to accept and set the priority class name:
 
 ```go
-// In pkg/controller/pod_volume_restore_controller.go
-priorityClassName, _ := kube.GetDataMoverPriorityClassName(ctx, namespace, kubeClient, configMapName)
+func (e *podVolumeExposer) createHostingPod(..., priorityClassName string) (*corev1api.Pod, error) {
+    // Log the priority class if it's set
+    if priorityClassName != "" {
+        e.log.Debugf("Setting priority class %q for data mover pod %s", priorityClassName, hostingPodName)
+    }
+    
+    pod := &corev1api.Pod{
+        // ... existing fields ...
+        Spec: corev1api.PodSpec{
+            // ... existing fields ...
+            PriorityClassName: priorityClassName,
+        },
+    }
+}
+```
 
-// Add priorityClassName to the pod spec
-pod := &corev1api.Pod{
+4. **Controller Setup**: Both controllers' setupExposeParam functions are updated to include the priority class:
+
+```go
+return exposer.PodVolumeExposeParam{
     // ... existing fields ...
-    Spec: corev1api.PodSpec{
-        // ... existing fields ...
-        PriorityClassName: priorityClassName,
-    },
+    // Priority class name for the data mover pod, retrieved from node-agent-configmap
+    PriorityClassName: r.dataMovePriorityClass,
 }
 ```
 
@@ -582,6 +624,102 @@ With the introduction of VGDP micro-services (as described in the VGDP micro-ser
 
 This ensures that all pods created by Velero for data movement operations (CSI snapshot data movement, PVB, and PVR) use a consistent approach for priority class name configuration through the node-agent-configmap.
 
+## ConfigMap Update Strategy
+
+Different Velero controllers handle ConfigMap updates using different strategies based on their operational patterns.
+
+### Centralized ConfigMap Watching
+
+The node-agent server reads and parses the ConfigMap during initialization and passes configurations (like `podResources`, `loadAffinity`, and `priorityClassName`) directly to controllers as parameters.
+
+#### Architecture
+
+```go
+// Centralized configuration provider interface
+type ConfigProvider interface {
+    GetConfigs() *Configs
+    RegisterHandler(handler ConfigUpdateHandler) string
+    UnregisterHandler(handlerID string)
+    Start(ctx context.Context) error
+    Stop()
+}
+
+// Updated controller structure - receives config from provider
+type PodVolumeBackupReconciler struct {
+    // ... existing fields ...
+    dataMovePriorityClass string
+    configProvider        ConfigProvider
+    configHandlerID       string
+}
+
+// Node-agent server creates single config provider
+func (s *nodeAgentServer) run() error {
+    configProvider, err := nodeagent.NewNodeAgentConfigProvider(
+        s.kubeClient, s.namespace, s.config.NodeAgentConfigMap, s.logger)
+    
+    // Pass config provider to all controllers
+    podVolumeBackupController := controller.NewPodVolumeBackupReconciler(
+        mgr.GetClient(), mgr, s.kubeClient, ..., configProvider)
+}
+```
+
+#### Benefits
+
+- Single ConfigMap reader/watcher for all controllers
+- All controllers receive updates simultaneously
+- Reduced resource usage with single watcher
+- Centralized configuration logic
+- Follows existing pattern of passing configs as parameters
+- Easier to mock configuration in tests
+
+### Maintenance Job Controller (Fresh Config Reads)
+
+The maintenance job controller (BackupRepoReconciler) reads fresh configuration from the ConfigMap each time a maintenance job is created:
+
+```go
+// Maintenance jobs read fresh config each time
+func (r *BackupRepoReconciler) buildMaintenanceJob(...) {
+    // Read fresh config from ConfigMap for each job creation
+    jobConfig, err := getJobConfig(ctx, r.Client, repo.Namespace, configMapName)
+    // ... use jobConfig.PriorityClassName directly
+}
+```
+
+**Rationale:**
+- Maintenance jobs are created infrequently (every 7 days for Restic, 1 hour for Kopia)
+- ConfigMap reads during job creation are acceptable performance-wise
+- Each job gets the most current configuration without caching complexity
+- Simpler implementation with no cache management or synchronization
+
+### Implementation Approach
+
+1. **Data Mover Controllers**: Receive configuration from centralized provider
+2. **Maintenance Job Controller**: Read fresh configuration from repo-maintenance-job-configmap at job creation time
+3. ConfigMap changes are reflected in newly created pods/jobs
+4. Use centralized provider for efficiency and consistency across data mover controllers
+
+### How Exposers Receive Configuration Updates
+
+CSI Snapshot Exposer and Generic Restore Exposer do not directly watch or read ConfigMaps. Instead, they receive configuration through their parent controllers following this flow:
+
+1. **ConfigMap Update Detection**: When the node-agent-configmap is updated, the centralized ConfigProvider detects the change through its Kubernetes informer.
+
+2. **Controller Notification**: The ConfigProvider notifies all registered handlers asynchronously. Data mover controllers (DataUploadReconciler, DataDownloadReconciler, PodVolumeBackupReconciler, PodVolumeRestoreReconciler) have registered handlers that update their internal `dataMovePriorityClass` field.
+
+3. **Configuration Propagation**: On the next reconciliation of a DataUpload/DataDownload/PodVolumeBackup/PodVolumeRestore resource:
+   - The controller calls `setupExposeParam()` which includes the current `dataMovePriorityClass` value
+   - For CSI operations: `CSISnapshotExposeParam.PriorityClassName` is set
+   - For generic restore: `GenericRestoreExposeParam.PriorityClassName` is set
+   - The controller passes these parameters to the exposer's `Expose()` method
+
+4. **Pod Creation**: The exposer creates new pods with the updated priority class name. Existing pods retain their original priority class.
+
+This design keeps exposers stateless and ensures:
+- Exposers remain simple and focused on pod creation
+- All configuration flows through controllers consistently
+- No complex state synchronization between components
+- Configuration updates are eventually consistent across all new pods
+
 ## Open Issues
 
 None.

pkg/cmd/cli/install/install.go

@@ -17,6 +17,7 @@ limitations under the License.
 package install
 
 import (
+	"context"
 	"fmt"
 	"os"
 	"path/filepath"
@@ -26,6 +27,7 @@ import (
 	"github.com/vmware-tanzu/velero/pkg/uploader"
 
 	"github.com/pkg/errors"
+	"github.com/sirupsen/logrus"
 	"github.com/spf13/cobra"
 	"github.com/spf13/pflag"
 	"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
@@ -91,6 +93,8 @@ type Options struct {
 	ItemBlockWorkerCount            int
 	NodeAgentDisableHostPath        bool
 	kubeletRootDir                  string
+	ServerPriorityClassName         string
+	NodeAgentPriorityClassName      string
 }
 
 // BindFlags adds command line values to the options struct.
@@ -194,6 +198,18 @@ func (o *Options) BindFlags(flags *pflag.FlagSet) {
 		o.ItemBlockWorkerCount,
 		"Number of worker threads to process ItemBlocks. Default is one. Optional.",
 	)
+	flags.StringVar(
+		&o.ServerPriorityClassName,
+		"server-priority-class-name",
+		o.ServerPriorityClassName,
+		"Priority class name for the Velero server deployment. Optional.",
+	)
+	flags.StringVar(
+		&o.NodeAgentPriorityClassName,
+		"node-agent-priority-class-name",
+		o.NodeAgentPriorityClassName,
+		"Priority class name for the node agent daemonset. Optional.",
+	)
 }
 
 // NewInstallOptions instantiates a new, default InstallOptions struct.
@@ -301,6 +317,8 @@ func (o *Options) AsVeleroOptions() (*install.VeleroOptions, error) {
 		ItemBlockWorkerCount:            o.ItemBlockWorkerCount,
 		KubeletRootDir:                  o.kubeletRootDir,
 		NodeAgentDisableHostPath:        o.NodeAgentDisableHostPath,
+		ServerPriorityClassName:         o.ServerPriorityClassName,
+		NodeAgentPriorityClassName:      o.NodeAgentPriorityClassName,
 	}, nil
 }
 
@@ -389,6 +407,23 @@ func (o *Options) Run(c *cobra.Command, f client.Factory) error {
 	if err != nil {
 		return err
 	}
+
+	// Get Kubernetes client for priority class validation
+	kubeClient, err := f.KubeClient()
+	if err != nil {
+		return err
+	}
+
+	// Validate priority classes if specified
+	logger := logrus.New()
+	logger.SetOutput(os.Stdout)
+	if o.ServerPriorityClassName != "" {
+		kubeutil.ValidatePriorityClass(context.Background(), kubeClient, o.ServerPriorityClassName, logger.WithField("component", "server"))
+	}
+	if o.NodeAgentPriorityClassName != "" {
+		kubeutil.ValidatePriorityClass(context.Background(), kubeClient, o.NodeAgentPriorityClassName, logger.WithField("component", "node-agent"))
+	}
+
 	errorMsg := fmt.Sprintf("\n\nError installing Velero. Use `kubectl logs deploy/velero -n %s` to check the deploy logs", o.Namespace)
 
 	err = install.Install(dynamicFactory, kbClient, resources, os.Stdout)