Add CLAUDE.md documentation for Claude Code integration

[akrzos]

Provides comprehensive development guidance for Claude Code when working with the Jetlag codebase, including:

• Essential commands for environment setup and cluster deployment
• Clear workflows for Red Hat Labs (Scale/Performance) and IBMcloud environments
• Coverage of all cluster types: MNO, SNO, VMNO, and hybrid deployments
• Architecture overview and critical configuration variables
• Environment-specific considerations and deployment patterns

🤖 Generated with Claude Code

Assisted-by: Claude (claude-sonnet-4@20250514)

[josecastillolema]

Humm maybe 4 (HMNO) and 5 (Hypervisor nodes) are the same and should be unified into HMNO?

[mcornea]

Can we also add a .claude/commands directory where to add usual commands for interacting with the repository? I personally use the following .claude/commands/jetlag-review.md command which helps reviewing PRs by running /jetlag-review PR#

---
description: Fetch and review a GitHub PR
---

You are tasked with reviewing a GitHub Pull Request. Follow these steps:

1. **Fetch PR details**: Use `gh pr view {{arg:1}}` to get PR information (title, description, author, files changed)

2. **Checkout the PR**: Use `gh pr checkout {{arg:1}}` to check out the PR branch locally

3. **Analyze the changes**:
   - Use `gh pr diff {{arg:1}}` to see the full diff
   - Read the modified files to understand the context
   - Pay attention to the PR description and any linked issues

4. **Provide a comprehensive review** covering:
   - **Summary**: Brief overview of what the PR does
   - **Code Quality**: Architecture, patterns, readability, maintainability
   - **Potential Issues**: Bugs, edge cases, security concerns, performance issues
   - **Testing**: Are tests adequate? Are there missing test cases?
   - **Documentation**: Is documentation updated if needed?
   - **Ansible-Specific Checks**:
     - **Idempotency**: Tasks should be idempotent (can be run multiple times safely)
     - **Module Selection**: Use of appropriate Ansible modules (avoid shell/command when native modules exist)
     - **Variable Naming**: Follow consistent naming conventions, proper scoping (group_vars, host_vars, role defaults)
     - **Task Naming**: All tasks have clear, descriptive names
     - **YAML Formatting**: Proper YAML syntax, consistent indentation, use of multi-line strings where appropriate
     - **Handlers**: Proper use of handlers for service restarts and notify/listen patterns
     - **Jinja2 Templates**: Correct usage of filters, tests, and variable references
     - **Error Handling**: Use of failed_when, changed_when, ignore_errors appropriately
     - **Tags**: Meaningful tags for task organization and selective execution
     - **Secrets Management**: No plain-text passwords, proper use of ansible-vault if applicable
     - **Conditionals**: Proper use of when clauses, check for undefined variables
     - **Loops**: Efficient use of loop, with_items, etc.
     - **Role Structure**: Follows standard role directory structure if roles are modified
     - **Deprecations**: No use of deprecated Ansible features or modules
     - **Performance**: Consideration of serial, async, poll for long-running tasks
   - **Suggestions**: Specific, actionable improvements with code examples where helpful

5. **Format your review** in a clear, structured markdown format that's easy to read

Be thorough but constructive. Focus on meaningful feedback that helps improve the code.

[josecastillolema]

/lgtm

[mcornea]

/lgtm

[mcornea]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mcornea

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mcornea]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment