Ansible Playbook Executor Skill

This skill executes Ansible remediation playbooks and tracks their execution status through the mock Ansible MCP server.

Integration with Remediator Agent: The sre-agents:remediator agent (invoked) orchestrates this skill as part of its Step 5 (Execute Playbook) workflow. For standalone playbook execution, you can invoke this skill directly.

When to Use This Skill

Use this skill directly when you need:

• Execute a previously generated Ansible playbook
• Track the status of a running playbook execution
• Monitor playbook job completion
• Verify playbook execution succeeded

Use the sre-agents:remediator agent when you need:

• Full remediation workflow including playbook execution
• Integrated CVE analysis → playbook generation → execution → verification
• End-to-end remediation orchestration

How they work together: The sre-agents:remediator agent (invoked) invokes this skill after generating a remediation playbook, asking the user for confirmation before execution, then monitoring the job to completion.

Workflow

1. Save Playbook to Temporary Location

CRITICAL: Playbooks MUST be saved under /tmp for container access

The ansible-mcp-server runs in a container with /tmp mounted to /playbooks. All playbooks must be saved to /tmp on the host.

import tempfile
import os

# Create temporary file with .yml extension in /tmp directory
temp_fd, temp_path = tempfile.mkstemp(suffix='.yml', prefix='remediation-', dir='/tmp')

# Write playbook content to file
with os.fdopen(temp_fd, 'w') as f:
    f.write(playbook_yaml_content)

# temp_path now contains the absolute path to the playbook file
# Example: /tmp/remediation-abc123.yml

Key Requirements:

• Playbook MUST be saved to /tmp directory (mounted into container as /playbooks)
• Playbook MUST be saved as a .yml or .yaml file
• Use absolute filesystem path starting with /tmp/ (not relative)
• File must exist and be readable before calling execute_playbook
• Keep track of temp_path for cleanup after completion

Critical: Human-in-the-Loop Requirements

This skill executes code on production systems. Explicit user confirmation is REQUIRED before playbook execution.

Before Playbook Execution (REQUIRED):

1. Display Playbook Path: Show which playbook file will be executed
2. Display Target Systems: Show which systems will be affected
3. Display Risk Assessment: Show reboot requirements, downtime estimates, affected services
4. Ask for Confirmation:

   ⚠️  CRITICAL: Playbook Execution Confirmation Required
   
   This playbook will:
   - Execute on: N production systems
   - Require reboot: [Yes/No]
   - Estimated downtime: X minutes per system
   - Affected services: [list]
   
   Playbook file: /tmp/remediation-CVE-YYYY-NNNNN.yml
   
   ❓ Execute this playbook now?
   
   Options:
   - "yes" or "execute" - Proceed with playbook execution
   - "review" - Show playbook content again
   - "abort" - Cancel execution
   
   Please respond with your choice.

5. Wait for Explicit Confirmation: Do not execute without "yes" or "execute"

Never assume approval - always wait for explicit user confirmation before executing playbooks on production systems.

2. Execute Playbook

ONLY after receiving explicit user confirmation, proceed with execution.

MCP Tool: execute_playbook (from ansible-mcp-server)

Parameters:

• playbook_path: Absolute path to playbook file in container filesystem
  • Example: "/playbooks/remediation-CVE-2024-1234.yml"
  • Format: MUST start with /playbooks/ (container mount point)
  • Conversion: Host path /tmp/file.yml → Container path /playbooks/file.yml

Path Conversion Logic:

IMPORTANT: Convert host path to container path before calling execute_playbook

Host path:      /tmp/remediation-CVE-2024-1234.yml
Container path: /playbooks/remediation-CVE-2024-1234.yml

Python conversion:
container_path = host_path.replace('/tmp/', '/playbooks/')

Expected Output:

{
  "job_id": "job_12345",
  "status": "PENDING",
  "playbook_path": "/playbooks/remediation-CVE-2024-1234.yml"
}

Verification:

✓ job_id returned (string - used for status tracking)
✓ status = "PENDING" (job queued for execution)
✓ playbook_path uses container path (/playbooks/)

Error Handling:

If playbook file not found:
→ Error: "Playbook file not found: /playbooks/remediation-CVE-2024-1234.yml"
→ Action: Verify file was saved to /tmp on host, check path conversion to /playbooks/

If execute_playbook fails:
→ Retry once after verifying file exists
→ If retry fails, report error to user with troubleshooting steps

3. Track Job Status

MCP Tool: get_job_status (from ansible-mcp-server)

Parameters:

• job_id: Job identifier from execute_playbook response
  • Example: "job_12345"
  • Format: String returned from execute_playbook

Expected Output (varies by job status):

// When PENDING
{
  "job_id": "job_12345",
  "status": "PENDING",
  "started_at": null,
  "completed_at": null
}

// When RUNNING
{
  "job_id": "job_12345",
  "status": "RUNNING",
  "started_at": "2024-01-20T15:30:02Z",
  "completed_at": null
}

// When COMPLETED
{
  "job_id": "job_12345",
  "status": "COMPLETED",
  "started_at": "2024-01-20T15:30:02Z",
  "completed_at": "2024-01-20T15:30:07Z"
}

Job Status Timeline Example:

T+0s:  Status: PENDING   (started_at: null, completed_at: null)
T+2s:  Status: RUNNING   (started_at: ISO8601, completed_at: null)
T+7s:  Status: COMPLETED (started_at: ISO8601, completed_at: ISO8601)

Status Transitions:
PENDING → RUNNING → COMPLETED

Polling Strategy:

1. Initial check: Immediately after execute_playbook
2. While status = "PENDING" or "RUNNING":
   - Wait 2 seconds
   - Call get_job_status(job_id=job_id)
   - Check status field
3. When status = "COMPLETED":
   - Stop polling
   - Report success

Status Interpretation:

Status: PENDING
→ Job queued, not yet started
→ Action: Continue polling

Status: RUNNING
→ Playbook execution in progress
→ Action: Continue polling, update user on progress

Status: COMPLETED
→ Playbook execution finished successfully
→ Action: Stop polling, report success

Status: FAILED (if supported by server)
→ Playbook execution encountered errors
→ Action: Report failure, provide troubleshooting guidance

Error Handling:

If get_job_status returns "Job not found":
→ Error: Invalid job_id or job expired
→ Action: Report error, suggest re-executing playbook

If polling timeout (>60 seconds):
→ Warning: Job taking longer than expected
→ Action: Continue polling but warn user

4. Report Execution Results

Generate execution summary with job details:

# Playbook Execution Report

## Job Details
**Job ID**: job_12345
**Status**: COMPLETED ✓
**Started At**: 2024-01-20T15:30:02Z
**Completed At**: 2024-01-20T15:30:07Z
**Duration**: 5 seconds

## Playbook Information
**Playbook Path**: /tmp/remediation-CVE-2024-1234.yml
**CVE**: CVE-2024-1234
**Target Systems**: 5 systems

## Execution Timeline
1. T+0s: Job submitted (PENDING)
2. T+2s: Execution started (RUNNING)
3. T+7s: Execution completed (COMPLETED)

## Next Steps
- Verify remediation success using remediation-verifier skill
- Check affected systems are no longer vulnerable
- Update vulnerability tracking system

5. Cleanup Temporary Files

After job completion, clean up temporary playbook file:

import os

# After job completes successfully
if os.path.exists(temp_path):
    os.remove(temp_path)
    print(f"Cleaned up temporary playbook: {temp_path}")

Cleanup Strategy:

• Remove temp file after COMPLETED status
• Keep temp file if FAILED status (for debugging)
• Warn user if cleanup fails (not critical)

Output Template

When completing playbook execution, provide output in this format:

# Ansible Playbook Execution

## Execution Started
**Playbook**: remediation-CVE-2024-1234.yml
**Job ID**: job_12345
**Status**: Submitted for execution

Monitoring job status...

## Status Updates
- T+0s: PENDING (job queued)
- T+2s: RUNNING (execution started)
- T+7s: COMPLETED (execution finished)

## Execution Complete ✓

**Job ID**: job_12345
**Status**: COMPLETED
**Duration**: 5 seconds
**Started**: 2024-01-20T15:30:02Z
**Completed**: 2024-01-20T15:30:07Z

## Next Steps
1. Verify remediation success:
   - Use remediation-verifier skill to confirm CVE is resolved
   - Check package versions on affected systems
   - Verify services are running properly

2. Update tracking:
   - Mark CVE-2024-1234 as remediated in vulnerability tracker
   - Document remediation in change management system

3. Monitor systems:
   - Watch for 24-48 hours for any issues
   - Verify Red Hat Lightspeed reflects patched status

Examples

Example 1: Execute Single CVE Remediation

User Request: "Execute the playbook for CVE-2024-1234"

Skill Response:

1. Receive playbook YAML content from agent
2. Save to /tmp/remediation-CVE-2024-1234.yml (host path)
3. Convert to container path: /playbooks/remediation-CVE-2024-1234.yml
4. Call execute_playbook(playbook_path="/playbooks/remediation-CVE-2024-1234.yml") → job_id: "job_12345", status: PENDING
5. Poll get_job_status every 2 seconds
6. Status changes: PENDING → RUNNING → COMPLETED
7. Report: "Playbook executed successfully in 5 seconds"
8. Cleanup temp file from /tmp/ on host
9. Suggest: "Use remediation-verifier skill to confirm success"

Example 2: Track Long-Running Playbook

User Request: "Check status of job_67890"

Skill Response:

1. Call get_job_status(job_id="job_67890")
2. Response: status: RUNNING, started_at: 2 minutes ago
3. Continue polling every 2 seconds
4. After 3 minutes: status: COMPLETED
5. Report: "Job completed successfully after 3 minutes"

Example 3: Handle Job Not Found

User Request: "Check status of job_99999"

Skill Response:

1. Call get_job_status(job_id="job_99999")
2. Response: "Job not found"
3. Report: "Job ID not found. Possible reasons: invalid ID, job expired, or execution completed and cleaned up"
4. Suggest: "Re-execute playbook if needed"

Error Handling

Playbook File Not Found:

Execution Failed: Playbook file not found

Container Path: /playbooks/remediation-CVE-2024-1234.yml
Host Path: /tmp/remediation-CVE-2024-1234.yml

Possible causes:
1. File was not saved to /tmp before calling execute_playbook
2. Path conversion from /tmp/ to /playbooks/ was not performed
3. File permissions prevent reading
4. Volume mount not configured correctly

Troubleshooting:
1. Verify file exists on host: ls -l /tmp/remediation-CVE-2024-1234.yml
2. Check file permissions: should be readable
3. Verify path conversion: /tmp/file.yml → /playbooks/file.yml
4. Ensure .mcp.json has volume mount: "-v", "/tmp:/playbooks:Z"
5. Ensure file has .yml or .yaml extension

Job Execution Timeout:

Execution Timeout: Job running longer than expected

Job ID: job_12345
Status: RUNNING
Duration: 65 seconds (exceeded 60s threshold)

Action: Continuing to monitor job status
Note: Some playbooks may take longer for large-scale remediations

Job Status Polling Error:

Status Check Failed: Unable to retrieve job status

Job ID: job_12345
Error: Network timeout

Troubleshooting:
1. Check ansible-mcp-server is running
2. Verify network connectivity
3. Retry status check manually: get_job_status(job_id="job_12345")

Dependencies

Required MCP Servers

• ansible-mcp-server - Mock Ansible playbook execution server (container-based)

Required MCP Tools

• execute_playbook (from ansible-mcp-server) - Submit playbook for execution
  • Parameters: playbook_path (string - absolute path in container filesystem starting with /playbooks/)
  • Returns: Job object with job_id, status, playbook_path
  • Note: Mock implementation validates path and creates test job
• get_job_status (from ansible-mcp-server) - Track execution progress
  • Parameters: job_id (string - job ID from execute_playbook)
  • Returns: Job status object with job_id, status (PENDING/RUNNING/COMPLETED), started_at, completed_at
  • Note: Mock implementation simulates job lifecycle

Related Skills

• mcp-ansible-validator - PREREQUISITE - Validates ansible-mcp-server before execution (invoke in Step 0 if not validated in session)
• playbook-generator - Generates playbooks that this skill executes
• remediation-verifier - Verifies success after this skill completes execution

Reference Documentation

• None required (execution skill)

Best Practices

1. Always save playbook to /tmp - Required for container volume mount access (mount: /tmp:/playbooks:Z)
2. Convert paths correctly - Host path /tmp/file.yml → Container path /playbooks/file.yml before calling execute_playbook
3. Require user confirmation - ALWAYS get explicit "yes" or "execute" before submitting playbook (HITL requirement)
4. Poll status efficiently - 2-second intervals balance responsiveness and overhead
5. Handle all status transitions - PENDING → RUNNING → COMPLETED (mock implementation)
6. Cleanup temp files - Remove after successful completion from /tmp/ on host
7. Provide progress updates - Keep user informed during polling with status messages
8. Link to verification - Always suggest remediation-verifier skill after execution completes
9. Keep temp files on failure - Useful for debugging failed executions
10. Use unique temp filenames - Include CVE ID or timestamp to avoid conflicts (e.g., remediation-CVE-2024-1234-{timestamp}.yml)

Integration with Other Skills

• playbook-generator: Generates playbooks that this skill executes
• remediation-verifier: Verifies success after this skill completes execution
• sre-agents:remediator agent: Orchestrates full workflow including playbook execution (invoked)

Orchestration Example (from sre-agents:remediator agent - invoked):

1. Agent invokes playbook-generator skill → Creates playbook YAML
2. playbook-generator skill asks for confirmation → User approves playbook content
3. Agent invokes playbook-executor skill → Skill asks for execution confirmation
4. User approves execution → Skill saves to temp file, executes, monitors
5. Skill reports: "Playbook executed successfully"
6. Agent invokes remediation-verifier skill → Confirms CVE resolved

Note: Both playbook-generator and playbook-executor require separate confirmations:

• playbook-generator: Confirms playbook content is acceptable
• playbook-executor: Confirms execution on production systems is approved

This two-step approval ensures user control over both what to run and when to run it.