NO-ISSUE: Render networks as comma-separated value

[mkowalski]

We have observed that the current way of rendering cluster and service networks as arrays of value generate the following bootstrap config

service-cluster-ip-range:
- 172.30.0.0/16
- fd65:172:16::/112

what subsequently creates the following kube-controller-manager pod manifest

args:
- --service-cluster-ip-range=172.30.0.0/16
- --service-cluster-ip-range=fd65:172:16::/112

what is interpreted as the running process as

FLAG: --service-cluster-ip-range="fd65:172:16::/112"

with the missing value. The reason for this is that the process takes into account only the last instance of the param and does not concatenate all the values provided.

In order to avoid this we are rendering the networks as a single comma-separated string so that the initial config file will contain now

service-cluster-ip-range:
- "172.30.0.0/16,fd65:172:16::/112"

Exactly the same pattern applies to the cluster networks that exist under cluster-cidr key.

Thanks to this kube-controller-manager process will be running with the correct set of networks.

Contributes-to: OCPBUGS-18641

[openshift-ci-robot]

@mkowalski: This pull request references Jira Issue OCPBUGS-18641, which is invalid:

• expected the bug to target the "4.15.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

We have observed that the current way of rendering cluster and service networks as arrays of value generate the following bootstrap config

service-cluster-ip-range:
- 172.30.0.0/16
- fd65:172:16::/112

what subsequently creates the following kube-controller-manager pod manifest

args:
- --service-cluster-ip-range=172.30.0.0/16
- --service-cluster-ip-range=fd65:172:16::/112

what is interpreted as the running process as

FLAG: --service-cluster-ip-range="fd65:172:16::/112"

with the missing value. The reason for this is that the process takes into account only the last instance of the param and does not concatenate all the values provided.

In order to avoid this we are rendering the networks as a single comma-separated string so that the initial config file will contain now

service-cluster-ip-range:
- "172.30.0.0/16,fd65:172:16::/112"

Exactly the same pattern applies to the cluster networks that exist under cluster-cidr key.

Thanks to this kube-controller-manager process will be running with the correct set of networks.

Contributes-to: OCPBUGS-18641

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[mkowalski]

After manual test (via clusterbot launch 4.14,openshift/cloud-provider-vsphere#47,openshift/cluster-kube-controller-manager-operator#745 vsphere,dualstack) I can see in the log of kube-controller-manager that networks are passed correctly, i.e.

flags.go:64] FLAG: --cluster-cidr="10.128.0.0/14,fd65:10:128::/56"
[...]
flags.go:64] FLAG: --service-cluster-ip-range="172.30.0.0/16,fd65:172:16::/112"

and the KubeControllerManagerConfig CR is rendered as

kind: KubeControllerManagerConfig
[...]
  cluster-cidr:
  - 10.128.0.0/14,fd65:10:128::/56
  service-cluster-ip-range:
  - 172.30.0.0/16,fd65:172:16::/112

/cc @rbbratta
/cc @JoelSpeed
/cc @cybertron

[mkowalski]

/retitle NO-ISSUE: Render networks as comma-separated value

[openshift-ci-robot]

@mkowalski: This pull request explicitly references no jira issue.

Details

In response to this:

We have observed that the current way of rendering cluster and service networks as arrays of value generate the following bootstrap config

service-cluster-ip-range:
- 172.30.0.0/16
- fd65:172:16::/112

what subsequently creates the following kube-controller-manager pod manifest

args:
- --service-cluster-ip-range=172.30.0.0/16
- --service-cluster-ip-range=fd65:172:16::/112

what is interpreted as the running process as

FLAG: --service-cluster-ip-range="fd65:172:16::/112"

with the missing value. The reason for this is that the process takes into account only the last instance of the param and does not concatenate all the values provided.

In order to avoid this we are rendering the networks as a single comma-separated string so that the initial config file will contain now

service-cluster-ip-range:
- "172.30.0.0/16,fd65:172:16::/112"

Exactly the same pattern applies to the cluster networks that exist under cluster-cidr key.

Thanks to this kube-controller-manager process will be running with the correct set of networks.

Contributes-to: OCPBUGS-18641

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cybertron]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cybertron, mkowalski
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Kubernetes Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[mkowalski]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[mkowalski]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mkowalski]

/reopen

[openshift-ci]

@mkowalski: Reopened this PR.

Details

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci]

@mkowalski: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.