Support namespace ExtendedOptions in cluster spec #282
Conversation
Codecov Report
@@ Coverage Diff @@
## master #282 +/- ##
==========================================
- Coverage 76.02% 75.99% -0.04%
==========================================
Files 32 32
Lines 2394 2416 +22
==========================================
+ Hits 1820 1836 +16
- Misses 429 432 +3
- Partials 145 148 +3 Continue to review full report at Codecov.
|
| // ExtendedOptions stores the extended namespace options. | ||
| type ExtendedOptions struct { | ||
| Type string `json:"type,omitempty"` | ||
| Options map[string]DynamicOption `json:"options,omitempty"` |
There was a problem hiding this comment.
I've never seen interface types in Kubernetes API types before. I wonder if having this be map[string]json.RawMessage would give you the same benefits (auto-generated DeepCopy implementation, more control over serialization) while being more Kubernetes-friendly?
There was a problem hiding this comment.
Thanks, @schallert , json.RawMessage really makes the implementation much simpler. Updated.
Sure, we've done some testing on a real cluster. |
* master: Backwards compatibility when using the original update annoation with an OnDelete update strategy (#284) Add support for parallel node updates within a statefulset (#283) Support namespace ExtendedOptions in cluster spec (#282) [controller] Support multi instance placement add (#275) [gomod] Update M3DB dependency (#277) [cmd] Fix instrument package name (#280) # Conflicts: # pkg/k8sops/annotations/annotations.go
This adds support for namespace
ExtendedOptionsfield in cluster spec map (passing its value to namespace create request, if present).Note that I have used intermediary transformation via json (from cluster spec to protobuf) to avoid implementing manual, error prone conversion of dynamic
map[string]interface{}which is used inExtendedOptions.