cert-manager/design/template.md

CHANGEME: Title

• Release Signoff Checklist
• Summary
• Motivation
  • Goals
  • Non-Goals
• Proposal
  • User Stories (Optional)
    • Story 1
    • Story 2
  • Notes/Constraints/Caveats (Optional)
  • Risks and Mitigations
• Design Details
  • Test Plan
  • Graduation Criteria
  • Upgrade / Downgrade Strategy
  • Supported Versions
• Production Readiness
• Drawbacks
• Alternatives

Release Signoff Checklist

This checklist contains actions which must be completed before a PR implementing this design can be merged.

• This design doc has been discussed and approved
• Test plan has been agreed upon and the tests implemented
• Feature gate status has been agreed upon (whether the new functionality will be placed behind a feature gate or not)
• Graduation criteria is in place if required (if the new functionality is placed behind a feature gate, how will it graduate between stages)
• User-facing documentation has been PR-ed against the release branch in [cert-manager/website]

Summary

Motivation

Goals

Non-Goals

Proposal

User Stories (Optional)

Story 1

Story 2

Notes/Constraints/Caveats (Optional)

Risks and Mitigations

Design Details

Test Plan

Graduation Criteria

Upgrade / Downgrade Strategy

Supported Versions

Production Readiness

How can this feature be enabled / disabled for an existing cert-manager installation?

Does this feature depend on any specific services running in the cluster?

Will enabling / using this feature result in new API calls (i.e to Kubernetes apiserver or external services)?

Will enabling / using this feature result in increasing size or count of the existing API objects?

Will enabling / using this feature result in significant increase of resource usage? (CPU, RAM...)

Drawbacks

Alternatives