mirror of
https://github.com/k3s-io/kubernetes.git
synced 2026-01-05 23:47:50 +00: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.