Address some review comments
Add to non-goals, risks, and upgrade strategy
@@ -49,22 +49,29 @@ daemonsets when the `managementState` field set to `Unmanaged`
### Goals
-Provide a method to disable the DNS operator without disabling the CVO
+Provide a method to disable the DNS operator without disabling the CVO.
### Non-Goals
-TODO
+- Do not support the `Force` option for `managementState` that is provided for
+ other operators. The `Force` state overrides other upgrade-blocking checks,
+ and can lead to unsuccessful upgrades.
+- Do not support the `Removed` option for `managementState` that is provided
+ for other operators. The `Removed` state means that the operator is actively
+ removing itself, which should not be done for DNS.
## Proposal
+Several other operators, including the apiserver, scheduler, storage, network,
+and console operators already implement the `managementState` field in order to
+disable the operator without needing to disabling the CVO. I propose that the
+DNS operator utilize the same field for consistency.
+
The DNS operator spec shall include the `managementState` field. The field will
accept two values:
- `Managed`: The DNS operator will manage CoreDNS configuration.
- `Unmanaged`: The DNS operator will not manage CoreDNS configuration.
-(TODO: is there anything the DNS operator will do regardless of the state of
-`managementState`?)
-
### User Stories
#### Story 1
@@ -85,7 +92,10 @@ TODO
### Risks and Mitigations
-TODO
+By adding the `managementState` field, it becomes easier for cluster admins to
+put cluster DNS into an unsupported, potentially broken state. In order to
+mitigate this, it is important to prominently state that setting
+`managementState` to `Unmanaged` is inherently unsupported.
## Design Details
@@ -107,8 +117,13 @@ TODO
### Upgrade / Downgrade Strategy
-Upgrades will leave `managementState` unset, which should be treated as being
-in a `Managed` configuration.
+When upgrading from 4.7 where `managementState` is not supported to 4.8,
+`managementState` will be left unset, which should be treated as being in a
+`Managed` configuration.
+
+In future upgrades, having `managementState` set to `Unmanaged` could put DNS
+in a state that would break on upgrade. As such, upgrades should be blocked
+until DNS is returned to the `Managed` state.
### Version Skew Strategy
