Stop trying to populate arbitrary cluster fields from the channel

[johngmyers]

When I refactored Spec.Networking to be a non-pointer, this code started forcing new clusters to have Kubenet.

This seems to be an extremely dubious feature.

[hakman]

Would it be safe to also start ignoring the the cluster field in ChannelSpec in general (maybe even removing it)?
/lgtm

[johngmyers]

This does ignore the cluster field in ChannelSpec. We can't remove it from the published channels, as the previous code requires it be present in order to look at the kubernetesVersion field of the appropriate kOps version.

[hakman]

I think the intention here was to be able to populate ClusterSpec from channels. I guess this is more or less unused.

[johngmyers]

Except it then overwrites large sections of the config.

The current code works only because it overwrites the kubenet setting in the channel with a blank networking struct.

[hakman]

This does ignore the cluster field in ChannelSpec. We can't remove it from the published channels, as the previous code requires it be present in order to look at the kubernetesVersion field of the appropriate kOps version.

I meant that, we could do something in API like Cluster *ClusterSpec json:"-"``, to make it clear that it's ignored and deprecated.

[hakman]

Let's go with it, we can optimise late if needed.
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hakman

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:

• OWNERS [hakman]

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

[k8s-triage-robot]

The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass.

This bot retests PRs for certain kubernetes repos according to the following rules:

• The PR does have any do-not-merge/* labels
• The PR does not have the needs-ok-to-test label
• The PR is mergeable (does not have a needs-rebase label)
• The PR is approved (has cncf-cla: yes, lgtm, approved labels)
• The PR is failing tests required for merge

You can:

• Review the full test history for this PR
• Prevent this bot from retesting with /lgtm cancel or /hold
• Help make our tests less flaky by following our Flaky Tests Guide

/retest

[johngmyers]

/retest