Cross-Cluster Pipeline Orchestration

Goals

Clients with limitations around resource access, such as VPNs, firewalls, etc, that restrict when/where certain pipeline activities can take place will benefit from this feature. Specifically, HCM is requesting this feature because it would facilitate the set up of integration testing and deployment for numerous HCM UI teams. The primary benefits are:

1. A common, supported mechanism that can be used to manage these scenarios with Konflux

2. A best practice established that is repeatable across various users

3. No need for home-rolled, brittle solutions that may try to implement this behavior on their own, resulting in brittle pipelines, increased security issues (punching holes in VPNs/firewalls is tricky business)

4. an easier onboarding ramp for internal CI/CD users with these kinds of limitations

More contextual information around this feature request can be found in this doc.

Requirements

Details around requirements are captured in the document linked above.

• • (Optional) Use Cases

< What are we making, for who, and why/what problem are we solving?>

Out of scope

N/A

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment