Skip to content
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

Merged
merged 1 commit into from
Dec 19, 2018

Conversation

squeed
Copy link
Contributor

@squeed squeed commented Nov 27, 2018

Adds the basic network configuration that downstream components may wish to configure.

@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Nov 27, 2018
@squeed
Copy link
Contributor Author

squeed commented Nov 27, 2018

cc @danwinship

Copy link
Contributor

@danwinship danwinship left a 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...

// vxlanPort
// ClusterNetworks []ClusterNetworkEntry `json:"clusterNetworks"`
// IP address pool to use for pod IPs.
ClusterNetworks []ClusterNetwork `json:"clusterNetworks"`
Copy link
Contributor

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.)

Copy link
Contributor Author

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


// IP address pool for services.
// Currently, we only support a single entry here.
ServiceNetworks []string `json:"serviceNetworks"`
Copy link
Contributor

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"`
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link

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.


// 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"`
Copy link
Contributor

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.)

Copy link
Contributor Author

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.

@@ -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.
Copy link
Contributor

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.
Copy link
Contributor

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

Copy link

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.

Copy link
Contributor

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.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@squeed
Copy link
Contributor Author

squeed commented Dec 3, 2018

Updated, PTAL, all.

// The complete block for pod IPs.
CIDR string `json:"cidr"`

// The size (prefix) of block to allocate to each node.
Copy link
Contributor

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"

@danwinship
Copy link
Contributor

lgtm

@squeed
Copy link
Contributor Author

squeed commented Dec 6, 2018

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?

@danwinship
Copy link
Contributor

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.

@squeed
Copy link
Contributor Author

squeed commented Dec 12, 2018

OK, updated to include MTU. This is ready for final approval / merge.

NetworkType string `json:"networkType"`

// ClusterNetworkMTU is the MTU for inter-pod networking.
ClusterNetworkMTU int `json:"podNetworkMTU"`
Copy link
Contributor

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

Copy link

@soltysh soltysh left a 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"`
Copy link

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.

@squeed
Copy link
Contributor Author

squeed commented Dec 19, 2018

@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.

@soltysh
Copy link

soltysh commented Dec 19, 2018

@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.
@squeed
Copy link
Contributor Author

squeed commented Dec 19, 2018

And, updated.

Copy link

@soltysh soltysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Dec 19, 2018
@openshift-ci-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 19, 2018
@openshift-merge-robot openshift-merge-robot merged commit cfbaa98 into openshift:master Dec 19, 2018
@squeed squeed deleted the network-status branch May 29, 2019 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants