Add operational criteria to Enhancement template #552
Conversation
|
/lgtm |
openshift-ci-robot
added
the
do-not-merge/hold
openshift-ci-robot
added
lgtm
guidelines/enhancement_template.md
Outdated
| @@ -189,12 +193,17 @@ These are generalized examples to consider, in addition to the aforementioned [m | |||
| - End user documentation, relative API stability | |||
| - Sufficient test coverage | |||
| - Gather feedback from users rather than just developers | |||
| - Enumerate service level objectives (SLIs), expose SLIs as metrics | |||
guidelines/enhancement_template.md
Outdated
| @@ -218,7 +227,7 @@ enhancement: | |||
|
|
|||
| Upgrade expectations: | |||
| - Each component should remain available for user requests and | |||
| workloads during upgrades. Any exception to this should be | |||
| workloads during upgrades. Ensure the components leverage best practices in handling voluntary disruption. Any exception to this should be | |||
There was a problem hiding this comment.
I don't follow. All components should be leveraging best practices. What is this specifically getting at?
There was a problem hiding this comment.
This PR is about making sure that we state operational best practices explicitly, without getting into implementation details. I could enumerate specifics here if you think it would be helpful, but it is really about following https://kubernetes.io/docs/concepts/workloads/pods/disruptions/ where applicable to the component.
There was a problem hiding this comment.
perhaps link it just so there's a reference in context?
| @@ -71,6 +71,7 @@ around the enhancement process. | |||
| - [ ] Enhancement is `implementable` | |||
| - [ ] Design details are appropriately documented from clear requirements | |||
| - [ ] Test plan is defined | |||
| - [ ] Operational readiness criteria is defined | |||
There was a problem hiding this comment.
This is vague to me. I like the idea, but I think there are probably 200 different ideas of what this means.
Specifically, I'm not sure if this is 'As an managed OpenShift SRE' or 'As a customer cluster operator'. I know it's partly both, but focusing on one or the other might help engineers understand what they actually need to be thinking about.
There was a problem hiding this comment.
Need to decide how much goes here vs another doc. I can link out, if you think that's the right approach.
There was a problem hiding this comment.
Summarizing our offline discussion; the enhancement template doesn't include details or links to other implementation guides, so we will continue that pattern here. I intend to find teams (maybe review some existing enhancements) to work with directly to gather some more detail.
There was a problem hiding this comment.
I think we should change that pattern, but ok for now given there's an effort to define these somewhere.
jeremyeder
force-pushed
the
operational-readiness-criteria
branch
from
ac02f34 to
51832d6
Compare
|
@derekwaynecarr @nstielau @crawford @sdodson comments addressed. Ready to merge? Plan to iterate, this being the first step. |
|
/lgtm |
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: derekwaynecarr The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
No description provided.