< High-Level description of the feature ie: Executive Summary >

Collect feature-level metrics for OpenShift Pipelines deployments so we understand how customers are deploying and using the product.

Goals

< Who benefits from this feature, and how? What is the difference between today’s current state and a world with this feature? >

Today we are only able to observe the number of clusters that have deployed OpenShift Pipelines, and can correlate its use with other operators on the cluster. However, we do not have deeper understanding of which features are enabled and configured. Teams are left guessing if a feature has been adopted, how its used, and impact if bugs/vulnerabilities are discovered.

Examples of feature level metrics we can collect:

• Enable/disable of optional components:
  • Results
  • Chains
  • Triggers
  • Pipelines as Code
• Sub-features within components (ex: configure external DB and logs for Results)
• Measures of utilization (ex: number of PipelineRuns created) and satisfaction (% success/failure rate, latency/performance of components).

Such metrics can also power Insights operator alerts if a customer enables an upstream feature that is not supported by Red Hat.

Requirements

• • (Optional) Use Cases

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

Out of scope

<Defines what is not included in this story>

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