Enable SCTP feature gate

[dougbtv]

This adds the SCTPSupport to the enabled-by-default feature gate flags.

[dougbtv]

/cc @squeed

[squeed]

/lgtm

[squeed]

@eparis observes this is an alpha feature. We do give users the ability to manage this themselves - see https://github.com/williamcaban/ocp4-sctp/blob/master/00-featuregate.yaml

/lgtm cancel

@fepan

[danwinship]

@eparis observes this is an alpha feature.

It's an alpha feature, but it's not an alpha feature, you know?

From an API stability point of view, the effect of enabling the feature gate is just that SCTP becomes an allowed value for the various port Protocol fields in Service, Pod, and NetworkPolicy, and there is basically a 0% chance that this behavior will change as the feature moves to beta and GA upstream. There's no real danger that we're going to get stuck supporting some dropped or deprecated API as a result of enabling this feature gate now.

From a code-untestedness point of view, the effect of enabling the feature gate is also very small; for one, if you don't actually define any SCTP pods/services/policies, then enabling the feature gate has no effect at all. (The "implementing SCTP" code is already enabled whether the feature gate is enabled or not; it's only the "allowing resources that use SCTP to be created" code that's gated.) If you do create SCTP pods/services/policies, then the only new code that gets hit is code for writing the string "sctp" into iptables/OVS/OVN rather than "tcp" or "udp". The SCTP feature is not getting a ton of use/testing upstream, so if there are bugs in iptables/OVS/OVN's handling of SCTP then they aren't going to get discovered until we actually let people use the feature...

[eparis]

If the network/sdn makes 2 commitments I think we should merge this.
#1 you agree to work upstream to get it beta
#2 you agree that you will support this API even if upstream changes it.
so it's up to Dan/Casey, but I lean towards letting this merge.

[danwinship]

yes, i'm working on moving upstream to beta: kubernetes/enhancements#1250
It missed 1.17 but it should happen for 1.18

[danwinship]

and yes, we already have all the code, so continuing to implement the feature as-is even if it changes upstream is no problem

[eparis]

sounds like we should rebase and merge this

[eparis]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dougbtv, eparis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [eparis]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment