Added canary rollout docs #8
Conversation
sivanov-nuodb
requested review from
adriansuarez,
agoelzer,
bkelly-ndb,
jleslie85 and
kontaras
sivanov-nuodb
changed the title
sivanov-nuodb
force-pushed
the
sivanov/DOC-4538
branch
2 times, most recently
from
0d29728 to
078842a
Compare
| ```text | ||
| LAST SEEN TYPE REASON OBJECT MESSAGE | ||
| 22m Normal CanaryPauseStep CanaryRollout/acme-upgrade Pause step (1/13) activated: canary rollout paused until manual approval | ||
| 21m Normal CanaryManuallyApproved CanaryRollout/acme-upgrade Pause step (1/13) manually approved after -1h59m59.509203822s |
There was a problem hiding this comment.
Nit: It is a bit silly that the pause duration was negative.
There was a problem hiding this comment.
Right. This is a side-effect from replacing the Paused condition instead of just changing its reason. To avoid this, we need to remember the LastTransitionTime before resetting the condition on manual approval. This is just a visual issue but I will remove this line to avoid confusion.
| A pre-defined database configuration preset in the form of [service tiers]({{< ref "./service-tiers.md" >}}) allows users to control fully supported and well-documented database properties. | ||
| Such a reusable configuration provides convenience for the users, but requires extra planning when a configuration change is made, since this will affect many databases. |
There was a problem hiding this comment.
I would reword this to make it clear that service tiers are managed by cluster operators / administrators. I think it might be hard for someone without an understanding of NuoDBaaS to understand why controlling the rollout of configuration changes is necessary.
The key points I would emphasize are:
- There are a handful of service tiers / managed configurations.
- A change to any of them generates a large set of upgrades that must be performed.
- Canary rollout gives control to cluster administrators over how they are rolled out.
It might make things clearer to give an example of what would happen if canary rollout did not exist, e.g. every database gets upgraded at the same time, which is potentially disruptive even if the configuration change made to the service tiers is correct, and catastrophic if the change was incorrect.
sivanov-nuodb
force-pushed
the
sivanov/DOC-4538
branch
from
078842a to
d285dbb
Compare
Changes
Added canary rollout docs - here.