-
Notifications
You must be signed in to change notification settings - Fork 518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config: add Network type #141
Conversation
cc @danwinship |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment on NetworkType
needs to be addressed. Other stuff is at your discretion...
config/v1/types_network.go
Outdated
// vxlanPort | ||
// ClusterNetworks []ClusterNetworkEntry `json:"clusterNetworks"` | ||
// IP address pool to use for pod IPs. | ||
ClusterNetworks []ClusterNetwork `json:"clusterNetworks"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, totally nitpicking since this may be the last chance to change these...
Technically there is only a single "cluster network", even if it's spread across multiple CIDR blocks. So maybe this should be singular? ("ClusterNetwork
") (And the struct type should not be called "ClusterNetwork" since it's only a subset of the cluster network.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a very good point; I was just duplicating what was done by openshift-sdn (in the interest of not rocking the boat too much). But you're right, this is a good chance to make this cleaner.
K8s is not the only one guilty of conflating the word "network" with "contiguous block of addresses."
Also, I know upstream calls it the ClusterCIDR, which makes me wonder if we should standardize on that. I don't like using the suffix "CIDR" to indicate an address block either.
Enough rambling. How about ClusterNetwork []ClusterNetworkBlock
config/v1/types_network.go
Outdated
|
||
// IP address pool for services. | ||
// Currently, we only support a single entry here. | ||
ServiceNetworks []string `json:"serviceNetworks"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise maybe single even though it's array-valued
|
||
// NetworkType is the plugin that is to be deployed (e.g. OpenShiftSDN). | ||
// N.B. changing this is currently not supported. | ||
NetworkType string `json:"networkType"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to explain what the set of possible values is or at least indicate where the canonical list is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changing this is currently not supported.
nit: specify that the change is not supported after installation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just making this a type and create constants matching the possible values. This will limit the scope of errors. We this in several places already.
config/v1/types_network.go
Outdated
|
||
// The size of subnet (in bits) to allocate to each node for pod allocations. | ||
// For example, 8 indicates a /24 will be given to each node. | ||
HostSubnetLength uint32 `json:"hostSubnetLength"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have always hated HostSubnetLength
's gratuitous backwardness, and managed to fix it when we added multiple CIDR support to ovn-kubernetes, where you now actually say "24
" when you want a /24, rather than saying "8
" to mean you want a /24. We should do that here too... and then we could perhaps even steal the "double CIDR" syntax that we use in the ovn-kubernetes config, and just specify each cluster network subset as a string, eg, "10.128.0.0/14/23"
rather than needing a struct type? (If we keep the struct, then we need to rename HostSubnetLength
too, to make it clear that it's not representing the same value as network.openshift.io.ClusterNetwork.HostSubnetLength. Maybe HostSubnetPrefix
. Or NodePrefix
for that matter.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NodePrefix
seems good to me. I don't like the double-slash.
config/v1/types_network.go
Outdated
@@ -13,20 +13,50 @@ type Network struct { | |||
// Standard object's metadata. | |||
metav1.ObjectMeta `json:"metadata,omitempty"` | |||
|
|||
// spec holds user settable values for configuration | |||
// Spec holds user settable values for configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deads2k mentioned in #139 (comment)
spec
to match the json tag
type NetworkStatus struct { | ||
// IP address pool to use for pod IPs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure when ObservedGeneration
is required. cc @deads2k
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we require OG
in config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure when
ObservedGeneration
is required. cc @deads2k
We need it when we're reconciling the workload resources to a particular level. I don't anticipate seeing it in these types.
config/v1/types_network.go
Outdated
Spec NetworkSpec `json:"spec"` | ||
// status holds observed values from the cluster. They may not be overridden. | ||
// Status holds observed values from the cluster. They may not be overridden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
48e3c78
to
630636c
Compare
Updated, PTAL, all. |
// The complete block for pod IPs. | ||
CIDR string `json:"cidr"` | ||
|
||
// The size (prefix) of block to allocate to each node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe explicitly note that this is the inverse of the 3.x "HostSubnetLength"
lgtm |
Here's another open question: Should we put the observed MTU in the NetworkStatus? Should administrators be able to configure the MTU in the NetworkSpec? |
We believe that we will be able to automatically guess the correct cluster-wide MTU for the vast majority of installations, so most users won't need to worry about it, so I'd say it doesn't need to be in the cluster NetworkSpec. (If it turns out that our powers of MTU prognostication aren't as good as we think, then we can add it later.) OTOH, putting the observed MTU in the NetworkStatus makes it easier for admins to see when we guessed it wrong, so I think it does make sense to put it there. |
630636c
to
474bf73
Compare
OK, updated to include MTU. This is ready for final approval / merge. |
474bf73
to
49b414d
Compare
config/v1/types_network.go
Outdated
NetworkType string `json:"networkType"` | ||
|
||
// ClusterNetworkMTU is the MTU for inter-pod networking. | ||
ClusterNetworkMTU int `json:"podNetworkMTU"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to update the json name to match the field name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dan's comment is still outstanding also see my proposal about type for NetworkType
|
||
// NetworkType is the plugin that is to be deployed (e.g. OpenShiftSDN). | ||
// N.B. changing this is currently not supported. | ||
NetworkType string `json:"networkType"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just making this a type and create constants matching the possible values. This will limit the scope of errors. We this in several places already.
@soltysh because we need to have some way of handling third-party network providers. It seems useful for the administrator to be able to specify, say, Calico, rather than Other. The effect on the network operator will be the same -- it will not install a network plugin -- but the true configuration is still discoverable. |
@squeed gotcha, that's fair. So only that nit from Dan is outstanding here. |
Adds the basic network configuration that downstream components may wish to configure.
49b414d
to
f578b4a
Compare
And, updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: soltysh, squeed The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Adds the basic network configuration that downstream components may wish to configure.