-
Outcome
-
Resolution: Unresolved
-
Major
-
None
-
None
-
0% To Do, 100% In Progress, 0% Done
-
False
-
Outcome Overview
Once all Features and/or Initiatives in this Outcome are complete, what tangible, incremental, and (ideally) measurable movement will be made toward the company's Strategic Goal(s)?
- Dramatically reduce overhead of running operators in standalone. Smaller reduction in hypershift.
- Dramatically reduce the capability differences between standalone and hypershift
- Dramatically improve testability of operators
number of phases/milestones with rough timelines/releases this will take
- POC that demonstrates viability of: consumption of synthetic resources, storage of mutation, secure application of mutation, and testability on one operator. Two developers, estimated three months.
- After demonstration of a viable POC, 3-5 can happen in parallel
- More developers (number informed by POC) to productize IndividualMOM required for responsible migration of standalone operators. Best guess (remember that the POC isn't even done yet), POC team plus two, for one release.
- One of the bigger items here is likely to be an independent static pod controller
- Standalone operator owners that need to run on HCP management cluster refactored by operator teams. Number of developers informed by POC. Best guess (remember that the POC isn't even done yet), 1/2 person per operator for one release.
- HCP specialists developer HyperMOM using already ported operators as a starting point. The shape of the transition informed by POC that shows an operational operator with real inputs/outputs. Best guess (remember that the POC isn't even done yet), two developers, two releases.
- UnifiedStandaloneMOM to allow the second transition after IndividualMOM to pull individual operators into a reduced runtime footprint. Best guess (remember that the POC isn't even done yet), just re-use the team from #3 for another release.
Success Criteria
What is the success criteria for this strategic outcome? Avoid listing Features or Initiatives and instead describe "what must be true" for the outcome to be considered delivered.
- Operators able to run intermittently, not a standing daemon
- Delivery of new features happens once instead of delivering once for hypershift and then implementing from scratch a second time on standalone (or vice versa)
- Operators have integration tests that can run locally (without a kube-apiserver) for both standalone and hypershift on management level operators.
Expected Results (what, how, when)
What incremental impact do you expect to create toward the company's Strategic Goals by delivering this outcome? (possible examples: unblocking sales, shifts in product metrics, etc. {}{} provide links to metrics that will be used post-completion for review & pivot decisions). {}For each expected result, list what you will measure and +when you will measure it (ex. provide links to existing information or metrics that will be used post-completion for review and specify when you will review the measurement such as 60 days after the work is complete)
Reducing the overhead of running operators in standalone improves customer utilization. On hypershift, it directly reduces the cost of running our services.
Reusing a single operator flow instead of building two parallel implementations will potentially halve the cost of delivering new features to OCP.
Testable operators improve reliability, eliminate unexpected emergent behavior, and make it much easier to reproduce field problems.
If the overall mechanism works well, we have a natural platform for management extensions on HCP.
Post Completion Review – Actual Results
After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).
- links to
