Goal:

Enable Satellite administrators to execute patching operations on managed hosts through natural language requests via MCP. Users can request that specific patches be applied to systems that require them, with the system automatically identifying target hosts, creating remote execution jobs, and applying the patches. This provides administrators with a streamlined way to remediate security vulnerabilities and apply updates without manually managing remote execution workflows.

Acceptance Criteria:

System Identification for Patching: Users can request via natural language to patch systems that need specific errata (e.g., RHSA-2025:1234)

• MCP server identifies hosts that require the specified errata and have access to it through their content views
• MCP server presents the list of target hosts to the user
• User confirms which hosts (specific ones, groups, or all) should receive the patch

Remote Execution Job Creation and Management: System creates and executes patching jobs for confirmed hosts

• MCP server creates remote execution jobs for patch installation on confirmed hosts
• Jobs are executed using Satellite's existing remote execution infrastructure
• Real-time job status and progress information is provided to the user
• Job results (success/failure/details) are reported back through MCP

Satellite-Only Scope: Initial implementation restricted to Satellite-managed hosts

• Capsule-registered hosts are out of scope for this Epic
• Focus on hosts directly managed by the central Satellite server

Integration with Existing Capabilities: Patching operations integrate seamlessly with existing MCP reporting features from 6.18

• Users can verify patching success using existing query capabilities
• Host patch status is accurately reflected in MCP-based reporting after job completion

Open questions:

1. How should the system handle hosts that are offline or unreachable when patch jobs are initiated?
2. What should be the default behavior for patch job scheduling - immediate execution or allow user-specified timing?
3. How should the system handle patch dependencies and prerequisite packages during remote execution?
4. Should there be automatic retry mechanisms for failed patch jobs, and if so, what retry policies?