mirror of
https://github.com/kubernetes/kubernetes.git
synced 2026-03-17 08:03:10 -04:00
ca8cfdcae9
This removes the old rest_tests and adds significantly more coverage. Maybe too much. The v4,v6 and v6,v4 tables are identical but for the order of families. This exposed that `trimFieldsForDualStackDowngrade` is called too late to do anything (since we don't run strategy twice any more). I moved similar logic to `PatchAllocatedValues` but I hit on some unclarity. Specifically, consider a PATCH operation. Assume I have a valid dual-stack service (with 2 IPs, 2 families, and policy either require or prefer). What fields can I patch, on their own, to trigger a downgrade to single-stack? I think patching policy to "single" is pretty clear intent. But what if I leave policy and only patch `ipFamilies` down to a single value (without violating the "can't change first family" rule)? Or what if I patch `clusterIPs` down to a single IP value? After much discussion, we decided to make a small API change (OK since we are beta). When you want a dual-stack Service you MUST specify the `ipFamilyPolicy`. Now we can infer less and avoid ambiguity. |
||
|---|---|---|
| .. | ||
| api | ||
| apis | ||
| auth | ||
| capabilities | ||
| client | ||
| cloudprovider | ||
| cluster/ports | ||
| controller | ||
| controlplane | ||
| credentialprovider | ||
| features | ||
| fieldpath | ||
| generated | ||
| kubeapiserver | ||
| kubectl | ||
| kubelet | ||
| kubemark | ||
| printers | ||
| probe | ||
| proxy | ||
| quota/v1 | ||
| registry | ||
| routes | ||
| scheduler | ||
| security | ||
| securitycontext | ||
| serviceaccount | ||
| util | ||
| volume | ||
| windows/service | ||
| .import-restrictions | ||
| OWNERS | ||