Orchestrator Development Planning Post Proof-of-Concept

Now that Orchestrator ostensibly works; it's time to start prioritizing the technical priorities to move it from Proof of Concept to Alpha.

This is a different exercise compared to creating the Product Roadmap.

The differences:

  • Product Roadmap
    • What is the next cloud provider to be selected?
    • What is our policy on support for Orchestrator?
    • How do we onboard new and existing customers?
  • Architectural Roadmap
    • What major refactors need to happen to move to Alpha and then Beta prior to General Availability
    • Identify issues that are clustered around a common bug/failure, quantify the problem for prioritization
    • Structure dependency relationships between each cluster of issues

Outputs

Planning

Technical Priorities to make Alpha

  • Release Process
    • Anyone consuming Orchestrator will require stability, so a release process is a must
  • Idempotency in all Tasks
    • without idempotency, failed jobs (e.g. transient network failures) cannot be run a second time
    • without idempotency, upgrades are far more dangerous
    • without idempotency, Orchestrator will give false positives for changed configuration
  • Understand the User Experience Targets
  • Provision module completeness
  • Orchestrate module completeness
    • we need to configure all the GitLab site object types that we provisioned
  • Test Plan for core features and Test Implementation
    • Pipeline Tests for core features to prevent regressions
  • Secrets Management
    • Orchestrator has to connect to remote resources. Even if secrets are stored elsewhere for GitLab itself, Orchestrator has to consume those secrets to make proper connections
    • SSL Handling unless we intend to also have SSL certificates live on a machine separate from the GitLab services
  • Site Pre-Flight Validations

cc @mendeni @ljlane

Edited by Robert Marshall