Context-aware advisor recommendations in Red Hat Lightspeed

In distributed system management, defining the "ideal state" of a server is rarely black and white. Different operational goals often create tension between performance tuning and security hardening, where optimizing for one can inadvertently break the other. To resolve this friction, Red Hat Lightspeed has introduced a new cross-service validation capability between our advisor and compliance services.

• Red Hat Lightspeed advisor: Recommendations for misconfigurations and best practices to improve stability, performance, and availability.
• Compliance: Monitors compliance with security baselines to report on and meet regulatory requirements at scale.

By bridging the logic between these services, you can now proactively detect when a performance recommendation contradicts a specific security policy. So when you're told to "fix" a system, you're not being told to create a compliance violation in the process.

How Lightspeed advisor recommendations work

To understand how conflicts happen, it's important to understand how Lightspeed advisor operates. The service is built on a foundation of recommendations: Python scripts that codify the expertise found in Red Hat Knowledgebase articles and support tickets.

These recommendations analyze the configuration of your systems for specific conditions. If a known issue is detected (like a database configuration that causes latency), it triggers a recommendation and provides a specific remediation, such as a command to install a missing package or tune a kernel parameter.

Problem: State contradiction

Recently, we identified a challenge where these two services—both operating correctly within their own scope—could create a deadlock for users. The issue arose when a performance and a security recommendation both target the same RPM or configuration file with opposing desired states. A common example involves the tuned RPM:

• Performance logic: Lightspeed advisor identifies a database workload and checks for thetunedRPM. If it is missing, the recommendation logic triggers: dnf install tuned.
• Security logic: The compliance scanner checks the active security profile. Many hardening guides (like a specific CIS level) explicitly require minimizing the attack surface by removing tuned.

For the user, this results in a flapping state where installing the tuned RPM to satisfy Lightspeed advisor causes the compliance scan to fail, and removing it to satisfy the compliance service triggers the advisor recommendation to reappear.

We realized that treating these recommendations in isolation was placing the burden of conflict resolution on the system administrator, often without the necessary context.

Solution: Cross-service validation logic

To fix this, we needed to move away from isolated recommendation evaluation and implement a cross-referencing layer. The goal was to detect these conflicts programmatically, both during our internal recommendation development and at runtime for the user.

We approached this by mapping the resolution data from Lightspeed advisor against the security content automation protocol (SCAP) content used by the compliance service.

1. Mapping the data

The challenge was that Lightspeed advisor recommendations are written in Python, while compliance rules rely on extensible configuration checklist description format (XCCDF) profiles. This meant we couldn't simply compare text strings. We needed a way to translate between imperative code and declarative security definitions.

To solve this, we built a conflict detection engine that parses the resolution steps of a Lightspeed advisor recommendation and queries the full library of supported compliance profiles (Red Hat Enterprise Linux 7 through 10) for rules that explicitly forbid that state.

2. Runtime context awareness

Identifying a theoretical conflict isn't enough. We need to know if it applies to a specific system. To bridge this gap, we updated the advisor frontend logic to check the system context. When the user interface renders a recommendation, it performs the following sequence:

We updated the advisor frontend logic to check the system context. When the user interface renders a recommendation:

1. It checks the recommended remediation ID
2. It queries the compliance service to see which policies are currently enabled and assigned to that specific inventory host
3. If the enabled policy contains a rule that conflicts with the remediation, a flag is raised

The result: Empowered decision-making

We deliberately decided against automatically suppressing conflicting recommendations. While hiding the conflict might result in a "cleaner" dashboard, it would obscure the critical context needed to manage your environment effectively.

In the real world, operational priorities vary. You might have a specific node where the database throughput is critical, and you are willing to accept a documented compliance exception to achieve it. By implementing a conditional alert rather than a silent suppression, we place the control back in your hands so you can make the decision that best fits your specific environment.

If a conflict is detected against an active policy, the Lightspeed advisor UI now injects a dynamic note into the remediation steps: "The resolution of this Lightspeed advisor recommendation conflicts with a rule defined in the compliance service. Applying this remediation may impact your compliance status," followed by the compliance policy name.

A new standard for recommendations

To prevent future conflicts from entering the ecosystem, we shifted validation left by integrating conflict detection directly into our internal development pipeline. Now, our CI process automatically validates new Lightspeed advisor recommendations against Red Hat Enterprise Linux security profiles before it hits production.

By bridging the logic gap between our performance and security datasets, we've ensured that Red Hat Lightspeed recommendations aren't just technically accurate in isolation, but operationally valid in the context of a hardened, compliant environment. Ultimately, this isn't just about cleaner code—it is about delivering the full context you need to make the right decisions for your infrastructure, rather than concealing the complexity behind a silent failure.

Try Red Hat Lightspeed today, included with your existing subscriptions.

For more information, visit https://www.redhat.com/en/lightspeed.