feat(enterprise): Phase 4 - Advanced support package features and automation

[joshrotenberg]

Phase 4 of Support Package Workflow

Part of #334 - Implementing first-class support package workflow
Depends on #337 (Phase 3)

Objectives

Add advanced features for filtering, automation, history tracking, and integration with monitoring systems.

Implementation Tasks

1. Advanced Filtering Options

# Time-based filtering
redisctl enterprise support-package cluster \
  --since "2024-01-10T00:00:00" \
  --until "2024-01-15T23:59:59"

# Component filtering
redisctl enterprise support-package cluster \
  --include-logs \
  --include-configs \
  --include-metrics \
  --exclude-sensitive

# Size management
redisctl enterprise support-package cluster \
  --max-size 1GB \
  --compress-level 9

2. Support Package History

// Store history in ~/.redisctl/support-packages.db
struct SupportPackageHistory {
    id: String,
    generated_at: DateTime<Utc>,
    cluster: String,
    type: PackageType,
    size: u64,
    path: PathBuf,
    case_number: Option<String>,
    upload_status: Option<UploadStatus>,
}

Commands:

# List generation history
redisctl enterprise support-package history
ID        Generated           Type      Size    Case     Status
sp-001    2024-01-15 14:30   Cluster   487MB   #12345   Uploaded
sp-002    2024-01-14 09:15   DB-1      125MB   #12346   Local
sp-003    2024-01-13 16:45   Node-2    89MB    -        Deleted

# Get details of specific package
redisctl enterprise support-package history sp-001

# Clean up old packages
redisctl enterprise support-package cleanup --older-than 30d

3. Automation and Scripting

# .redisctl/support-package-preset.yml
presets:
  incident:
    type: cluster
    time_range: 1h
    components:
      - logs
      - metrics
      - configs
    compress_level: 6
    
  daily:
    type: cluster
    time_range: 24h
    components:
      - configs
      - stats
    max_size: 500MB

Usage:

# Use preset
redisctl enterprise support-package create --preset incident

# Script-friendly output
redisctl enterprise support-package cluster --json
{
  "task_id": "abc123",
  "status": "completed",
  "file_path": "/path/to/package.tar.gz",
  "size_bytes": 510656512
}

4. Monitoring Integration

# Webhook notification on completion
redisctl enterprise support-package cluster \
  --webhook https://slack.webhook.url \
  --webhook-on-complete

# Integration with alerting
redisctl enterprise support-package cluster \
  --trigger-on-alert "high_memory" \
  --auto-upload

5. Direct Upload to Support (Future)

# Direct upload with case number
redisctl enterprise support-package upload \
  support-package-2024-01-15.tar.gz \
  --case 12345 \
  --description "High memory usage issue"

# Upload with progress
Uploading to Redis Support...
[████████████░░░░] 75% - 365MB / 487MB - 2m remaining
✓ Upload complete
  Case: #12345
  Package ID: pkg-789xyz
  Support URL: https://support.redis.com/cases/12345

6. Scheduled Generation

# Schedule regular generation (cron-like)
redisctl enterprise support-package schedule \
  --cron "0 2 * * *" \
  --type cluster \
  --output-dir /backup/support-packages \
  --retain 30

# List scheduled jobs
redisctl enterprise support-package schedule list
ID    Schedule      Type      Next Run         Status
s01   Daily 2am     Cluster   2024-01-16 02:00 Active
s02   Weekly Sun    DB-1      2024-01-21 00:00 Active

7. Package Validation

# Validate package integrity
redisctl enterprise support-package validate support-package.tar.gz
✓ Package structure valid
✓ All required files present
✓ Checksums verified
✓ Package can be processed by Redis Support

# Extract specific files
redisctl enterprise support-package extract \
  support-package.tar.gz \
  --file cluster.json \
  --output ./

8. Diagnostics Mode

# Run diagnostics before generating package
redisctl enterprise support-package diagnose
Checking cluster health...
⚠ Warning: High memory usage on node-2 (89%)
⚠ Warning: Slow replication on DB-3
✓ No critical issues found

Recommended package type: Full cluster with metrics
Include last: 7 days (to capture memory trend)

Generate recommended package? (y/n)

Configuration File Support

# ~/.redisctl/config.toml
[support_packages]
default_output_dir = "/var/log/redis-support"
auto_compress = true
compress_level = 6
include_sensitive = false
max_size = "1GB"
history_retention_days = 90

[support_packages.upload]
endpoint = "https://support.redis.com/api/v1/upload"
api_key = ""
auto_upload = false

Testing Requirements

• Test all filtering options
• Test history tracking and cleanup
• Test preset system
• Test webhook notifications
• Test scheduled generation
• Test package validation
• Test configuration file parsing

Documentation

• Advanced filtering guide
• Automation examples
• Integration patterns
• Best practices for CI/CD
• Troubleshooting guide

Definition of Done

• All filtering options work
• History tracking implemented
• Preset system functional
• Webhook notifications work
• Package validation implemented
• Configuration file support
• All tests pass
• Comprehensive documentation

Branch Name

feat/support-package-phase-4

This phase adds power-user features and enables full automation of support package generation for enterprise environments.

Future Considerations

• Integration with Redis Insight
• Support for multiple cluster management
• AI-powered diagnostics suggestions
• Automatic issue detection and package generation

[joshrotenberg]

❌ Phase 4 Not Feasible - API Limitations

After researching the Redis Enterprise REST API, most Phase 4 objectives aren't achievable due to API limitations:

What's NOT possible:

• ❌ Advanced filtering (API returns pre-packaged tar.gz files, no query parameters)
• ❌ Component selection (can't exclude logs, metrics, etc.)
• ❌ Time range filtering (no time parameters supported)
• ❌ Direct upload to Redis Support (no upload API endpoint exists)
• ❌ Support package history (API doesn't track previous packages)

What we achieved in Phase 2:

• ✅ Automation via JSON output
• ✅ Smart file naming with timestamps
• ✅ Pre-flight validation (disk space, permissions)
• ✅ Configuration via profiles and environment variables

Conclusion:
The current implementation in Phase 2 (PR #341) maximizes what's possible with the existing API. Redis Enterprise would need to add new API endpoints to enable these advanced features.

The manual step of uploading to support remains on Redis's side to solve - as noted in their docs: "Upload the tar file to Redis support."

[joshrotenberg]

Consolidated into epic issue #379 for better tracking. See #379 for complete status and roadmap.