F5 Managed iRule Reconciler

Overview

The F5 Managed iRule Reconciler is an automated background process within the admin service that ensures the managed F5 BIG-IP iRules deployed on gateway appliances are always synchronized with the current running version of the platform.

This component solves the problem of "stale" iRule logic persisting on an appliance after a platform upgrade. Previously, iRules were only updated by an explicit operator action, such as applying a log forwarding configuration. This meant a platform upgrade could be released and deployed, but the gateway appliances might continue to execute an older, potentially defective iRule indefinitely. This could cause fixed defects to persist in production, as the part of the code running on the appliance was not updated.

The reconciler automates this update process. It operates on a "desired state" principle: it periodically checks each configured F5 instance and updates its managed iRules if they do not match the version included with the current software build. This process is designed to be fail-open, meaning an unreachable or misconfigured appliance will not block a platform deployment or crash the admin service.

How It Works

The reconciliation process runs automatically on a schedule. It is designed to be narrow in scope, safe by default, and resilient to appliance-side failures.

Scheduling and Execution

The reconciler is a scheduled task that runs periodically:

1. Initial Run: The first reconciliation task begins after an initial delay following application startup. This delay allows the service to become fully operational before initiating potentially long-running calls to external appliances. The default initial delay is 2 minutes (PT2M).
2. Periodic Runs: After the initial run, the task executes at a fixed interval to act as a safety net. This ensures that any appliance that was unreachable or had incorrect credentials during a previous attempt will be reconciled on a subsequent pass. The default interval is 6 hours (PT6H).

The entire feature can be disabled by setting the s2r.f5.managed-rule-reconcile-enabled configuration property to false.

Reconciliation Flow

The reconcileManagedRules method orchestrates the process. The following diagram illustrates the sequence of operations for each scheduled run.

flowchart TD
    A[Scheduler triggers task] --> B{Reconciler enabled?};
    B -- No --> Z[Stop];
    B -- Yes --> C[Read all configured F5 instances];
    C -- Fails --> D[Log warning and stop run];
    C -- Succeeds --> E[For each enabled F5 instance];
    E --> F[Call discovery service to reconcile rules];
    subgraph "On F5 Appliance"
        F --> G[Compare active iRule body with current platform version];
    end
    F -- Fails --> H[Log warning and proceed to next instance];
    G --> I{Is iRule stale?};
    I -- Yes --> J[Update iRule body];
    J --> K[Log INFO: Stale rule updated];
    I -- No --> L{Reconciliation failed?};
    L -- Yes --> M[Log WARN: Reconciliation failed];
    L -- No --> N[Log DEBUG: Rule is current];
    K --> O[End for instance];
    M --> O;
    N --> O;

The core logic for a single appliance is handled by the reconcileOne method:

1. The reconciler fetches the list of all known F5InstanceRecord objects from the repository.
2. It iterates through each instance, skipping any that are not marked as enabled.
3. For each enabled instance, it calls the f5DiscoveryService.reconcileManagedTrafficRules method, providing the necessary settings for that instance.
4. It inspects the result:
   • If the updatedStages field in the response contains entries, it means one or more iRule bodies were stale and have been rewritten. A detailed INFO log message is generated to make this event visible.
   • If the overallStatus is failed, a WARN log is generated with the failureReason.
   • If no changes were made and the operation was successful, a DEBUG log is generated.

Any exception during the processing of one appliance is caught and logged. The reconciler then proceeds to the next appliance, ensuring that a single failing instance does not halt the entire process.

Example Log Output

The reconciler does not expose a direct API or CLI. Its operation is observed through application logs. When the reconciler finds and updates a stale iRule on an appliance, it generates a log message similar to the following.

S2R-F5-IRULE-RECONCILE instance=my-f5-gateway-01 rewrote stale managed iRules stages=[s2r_managed_req, s2r_managed_resp] status=succeeded

This log entry indicates that for the F5 instance named my-f5-gateway-01, the reconciler found that the iRule bodies were out of date and successfully updated them. Observing this message confirms that the reconciler is functioning correctly and has corrected a stale configuration.

Configuration Reference

The behavior of the F5 Managed iRule Reconciler can be configured through the following properties.

Troubleshooting

The reconciler is designed to be "fail-open," meaning failures will be logged but will not interrupt the main application. Key log messages can help diagnose issues.

See Also

• F5 Log Forwarding Configuration: The reconciler updates existing iRules, but the applyLogForwarding action is the only mechanism that attaches these iRules to virtual servers.
• Fleet Sync Runner: The source notes that the FleetSyncRunner component follows a similar "event-plus-safety-net" scheduling pattern.

All SOAP-to-REST docs