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

Bug 2007106: Extend dual-stack network subnet validations #2660

Merged
merged 1 commit into from Oct 4, 2021

Conversation

mkowalski
Copy link
Contributor

@mkowalski mkowalski commented Sep 23, 2021

Assisted Pull Request

Description

This commit extends the validations performed for dual-stack OCP
clusters by making sure the following requirements are met if a cluster
is dual-stack

  • exactly 2 machine networks are provided (if any)
  • exactly 2 service networks are provided
  • exactly 2 cluster networks are provided
  • for every list containing 2 networks, the first one has to be IPv4 and
    the second one IPv6

Closes-bug: #2007106
Contributes-to: #2005440
Closes: OCPBUGSM-35447
Contributes-to: OCPBUGSM-35273

List all the issues related to this PR

  • New Feature
  • Bug fix
  • Tests
  • Documentation
  • CI/CD

What environments does this code impact?

  • Automation (CI, tools, etc)
  • Cloud
  • Operator Managed Deployments
  • None

How was this code tested?

  • assisted-test-infra environment
  • dev-scripts environment
  • Reviewer's test appreciated
  • Waiting for CI to do a full test run
  • Manual (Elaborate on how it was tested)
  • No tests needed

Manual test for single service network

KubeAPI

time="2021-09-28T11:38:22Z" level=error msg="Failed to registered cluster test-infra-cluster-assisted-installer-debug with id c89e1293-7b2e-4959-bc1a-b6934a20a6f3" func="github.com/openshift/assisted-service/internal/bminventory.(*bareMetalInventory).RegisterClusterInternal.func1" file="/go/src/github.com/openshift/origin/internal/bminventory/inventory.go:419" cluster_id=c89e1293-7b2e-4959-bc1a-b6934a20a6f3 error="Expected 2 service networks, found 1" go-id=661 pkg=Inventory request_id=98aee5cf-5531-440d-bbe4-8e986964c42b
status:
  conditions:
  - lastProbeTime: "2021-09-28T11:38:17Z"
    lastTransitionTime: "2021-09-28T11:38:17Z"
    message: 'The Spec could not be synced due to an input error: Expected 2 service
      networks, found 1'
    reason: InputError
    status: "False"
    type: SpecSynced

Rest API

[root@edge-14 ~]# export PAYLOAD='{"vip_dhcp_allocation":true,"network_type":"OVNKubernetes","user_managed_networking":false,"cluster_networks":[{"cidr":"10.128.0.0/14","host_prefix":23},{"cidr":"fd01::/48","host_prefix":64}],"service_networks":[{"cidr":"172.30.0.0/16"}],"machine_networks":[{"cidr":"192.168.127.0/24"},{"cidr":"1001:db8::/120"}]}'
[root@edge-14 ~]# curl --data $PAYLOAD -H "content-type: application/json" --request PATCH http://chocobomb.lab/api/assisted-install/v1/clusters/$CLUSTER
{"code":"400","href":"","id":400,"kind":"Error","reason":"Expected 2 service networks, found 1"}

The service is not crashing. Test succeeded.

Manual test for single machine network

KubeAPI

Does not throw an error yet, that's why only Contributes-to: #2005440 and not Closes-bug: #2005440

Rest API

[root@edge-14 ~]# export PAYLOAD='{"vip_dhcp_allocation":true,"network_type":"OVNKubernetes","user_managed_networking":false,"cluster_networks":[{"cidr":"10.128.0.0/14","host_prefix":23},{"cidr":"fd01::/48","host_prefix":64}],"service_networks":[{"cidr":"172.30.0.0/16"},{"cidr":"fd02::/112"}],"machine_networks":[{"cidr":"192.168.127.0/24"}]}' 
[root@edge-14 ~]# curl --data $PAYLOAD -H "content-type: application/json" --request PATCH http://chocobomb.lab/api/assisted-install/v1/clusters/$CLUSTER
{"code":"400","href":"","id":400,"kind":"Error","reason":"Expected 2 machine networks, found 1"}

Assignees

/cc @flaper87
/cc @YuviGold
/cc @ori-amizur

Checklist

  • Title and description added to both, commit and PR.
  • Relevant issues have been associated (see CONTRIBUTING guide)
  • Reviewers have been listed
  • This change does not require a documentation update (docstring, docs, README, etc)
  • Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

  • Are the title and description (in both PR and commit) meaningful and clear?
  • Is there a bug required (and linked) for this change?
  • Should this PR be backported?

@openshift-ci openshift-ci bot added bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Sep 23, 2021
@openshift-ci
Copy link

openshift-ci bot commented Sep 23, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is invalid:

  • expected the bug to target the "4.10.0" release, but it targets "---" instead

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

In response to this:

Bug 2007106: Extend dual-stack network subnet validations

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.

1 similar comment
@openshift-ci
Copy link

openshift-ci bot commented Sep 23, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is invalid:

  • expected the bug to target the "4.10.0" release, but it targets "---" instead

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

In response to this:

Bug 2007106: Extend dual-stack network subnet validations

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 openshift-ci bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Sep 23, 2021
@mkowalski
Copy link
Contributor Author

/test e2e-metal-assisted-operator-ztp
/test e2e-metal-assisted-operator-ztp-multinode-spoke
/test e2e-metal-assisted-operator-ztp-dualstack
/test e2e-metal-assisted-operator-ztp-dualstack-multinode-spoke

@mkowalski
Copy link
Contributor Author

/test e2e-metal-assisted-kube-api

Traceback (most recent call last):
  File "discovery-infra/start_discovery.py", line 1261, in <module>
    main()
  File "discovery-infra/start_discovery.py", line 905, in main
    execute_kube_api_flow()
  File "discovery-infra/start_discovery.py", line 819, in execute_kube_api_flow
    nodes_flow_kube_api(cluster_name, machine_net, cluster_deployment, agent_cluster_install)
  File "discovery-infra/start_discovery.py", line 609, in nodes_flow_kube_api
    kubeconfig_path=utils.get_kubeconfig_path(cluster_name)
  File "/home/assisted/discovery-infra/install_cluster.py", line 219, in run_installation_flow_kube_api
    Agent.wait_for_agents_to_install(agents)
TypeError: wait_for_agents_to_install() missing 1 required positional argument: 'nodes_number'

@mkowalski
Copy link
Contributor Author

/test ci/prow/subsystem-kubeapi-aws

@openshift-ci
Copy link

openshift-ci bot commented Sep 23, 2021

@mkowalski: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

  • /test ci-index
  • /test e2e-metal-assisted
  • /test e2e-metal-assisted-kube-api
  • /test e2e-metal-assisted-multi-version
  • /test e2e-metal-assisted-operator-ztp
  • /test images
  • /test lint
  • /test subsystem-aws
  • /test subsystem-kubeapi-aws

The following commands are available to trigger optional jobs:

  • /test e2e-metal-assisted-ipv6
  • /test e2e-metal-assisted-networking
  • /test e2e-metal-assisted-none
  • /test e2e-metal-assisted-olm
  • /test e2e-metal-assisted-operator-disconnected
  • /test e2e-metal-assisted-operator-ztp-dualstack
  • /test e2e-metal-assisted-operator-ztp-dualstack-multinode-spoke
  • /test e2e-metal-assisted-operator-ztp-multinode-spoke
  • /test e2e-metal-assisted-single-node

Use /test all to run the following jobs that were automatically triggered:

  • pull-ci-openshift-assisted-service-master-ci-index
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted-kube-api
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted-networking
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted-operator-ztp
  • pull-ci-openshift-assisted-service-master-images
  • pull-ci-openshift-assisted-service-master-lint
  • pull-ci-openshift-assisted-service-master-subsystem-aws
  • pull-ci-openshift-assisted-service-master-subsystem-kubeapi-aws

In response to this:

/test ci/prow/subsystem-kubeapi-aws

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.

@mkowalski
Copy link
Contributor Author

/test subsystem-kubeapi-aws

@mkowalski
Copy link
Contributor Author

/hold

It may be failing for a reason. Need to investigate

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 23, 2021
@flaper87
Copy link
Contributor

/bugzilla refresh

@openshift-ci openshift-ci bot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Sep 27, 2021
@openshift-ci
Copy link

openshift-ci bot commented Sep 27, 2021

@flaper87: This pull request references Bugzilla bug 2007106, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.10.0) matches configured target release for branch (4.10.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

No GitHub users were found matching the public email listed for the QA contact in Bugzilla (yobshans@redhat.com), skipping review request.

In response to this:

/bugzilla refresh

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 openshift-ci bot removed the bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. label Sep 27, 2021
@mkowalski
Copy link
Contributor Author

/hold cancel

/test e2e-metal-assisted-operator-ztp
/test e2e-metal-assisted-operator-ztp-multinode-spoke
/test e2e-metal-assisted-operator-ztp-dualstack
/test e2e-metal-assisted-operator-ztp-dualstack-multinode-spoke

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 28, 2021
@openshift-ci
Copy link

openshift-ci bot commented Sep 28, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.10.0) matches configured target release for branch (4.10.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

No GitHub users were found matching the public email listed for the QA contact in Bugzilla (yobshans@redhat.com), skipping review request.

In response to this:

Bug 2007106: Extend dual-stack network subnet validations

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.

Comment on lines -12628 to 12499
clusterNetworksWrongOrder := common.TestDualStackNetworking.ClusterNetworks
clusterNetworksWrongOrder := TestDualStackNetworkingWrongOrder.ClusterNetworks
clusterNetworksWrongOrder[0], clusterNetworksWrongOrder[1] = clusterNetworksWrongOrder[1], clusterNetworksWrongOrder[0]

serviceNetworksWrongOrder := common.TestDualStackNetworking.ServiceNetworks
serviceNetworksWrongOrder := TestDualStackNetworkingWrongOrder.ServiceNetworks
serviceNetworksWrongOrder[0], serviceNetworksWrongOrder[1] = serviceNetworksWrongOrder[1], serviceNetworksWrongOrder[0]

machineNetworksWrongOrder := common.TestDualStackNetworking.MachineNetworks
machineNetworksWrongOrder := TestDualStackNetworkingWrongOrder.MachineNetworks
machineNetworksWrongOrder[0], machineNetworksWrongOrder[1] = machineNetworksWrongOrder[1], machineNetworksWrongOrder[0]
Copy link
Contributor

Choose a reason for hiding this comment

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

Can be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure...

If you look at the definition

TestDualStackNetworkingWrongOrder = common.TestNetworking{
			ClusterNetworks: append(common.TestIPv4Networking.ClusterNetworks, common.TestIPv6Networking.ClusterNetworks...),
			ServiceNetworks: append(common.TestIPv4Networking.ServiceNetworks, common.TestIPv6Networking.ServiceNetworks...),
			MachineNetworks: append(common.TestIPv4Networking.MachineNetworks, common.TestIPv6Networking.MachineNetworks...),
			APIVip:          common.TestIPv4Networking.APIVip,
			IngressVip:      common.TestIPv4Networking.IngressVip,
		}

it creates TestDualStackNetworkingWrongOrder as concatenation of IPv4 networks and IPv6 networks (so the order is still correct). Only afterwards we are doing

	clusterNetworksWrongOrder := TestDualStackNetworkingWrongOrder.ClusterNetworks
	clusterNetworksWrongOrder[0], clusterNetworksWrongOrder[1] = clusterNetworksWrongOrder[1], clusterNetworksWrongOrder[0]
        [...]

so in the structure built above we are reversing 1st and 2nd subnet. As there is a bunch of pointers hidden inside, modifying elements of clusterNetworksWrongOrder is in fact modifying content of TestDualStackNetworkingWrongOrder.ClusterNetworks

Or did I miss something simpler here ?

internal/cluster/validations/validations.go Outdated Show resolved Hide resolved
// * there are exactly two machine networks
// * the first one is IPv4 subnet
// * the second one is IPv6 subnet
func VerifyMachineNetworksDualStack(networks []*models.MachineNetwork, isDualStack bool) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you do some magic for these 3 duplicated functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was considering this, but my logic was as follows - today all the requirements are the same for those networks

  • max 2 entries
  • first one v4
  • and so on...

But those requirements in the upstream OCP are not aligned, e.g. the limit of clusterNetworks is something we impose as AI, but OCP does not. It should be relatively easy for us to support it, but we'd need to test it extensively so as for today, we don't. However, it already boils down to saying that in a very near future we will have different sets of requirements for different networks. As soon as we need to implement those, we'd need to undo the magic because the same function will not be able to handle different cases.

So, instead of this back-and-forth, I went with the simplest way that is - today we have 3 functions that look almost the same, but it enables us to already now modify validators independently.

What do you think ?

cc @flaper87 @celebdor

Copy link
Contributor

Choose a reason for hiding this comment

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

I would also add that these 3 networks are not ruled by the same assumptions, either in OCP or in Assisted. Although it looks like that right now. The implementation would also be a bit hacky.

I would go the python way here, explicit is better than implicit (and the type system is guiding us that way)

@mkowalski mkowalski force-pushed the bz2007106 branch 2 times, most recently from c035bcc to cb23224 Compare October 1, 2021 10:44
@openshift-ci openshift-ci bot added bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. and removed bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. labels Oct 1, 2021
@openshift-ci
Copy link

openshift-ci bot commented Oct 1, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is invalid:

  • expected the bug to target the "2.5.0" release, but it targets "4.10.0" instead

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

In response to this:

Bug 2007106: Extend dual-stack network subnet validations

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.

@mkowalski
Copy link
Contributor Author

/bugzilla refresh

@openshift-ci
Copy link

openshift-ci bot commented Oct 1, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is invalid:

  • expected the bug to target the "2.5.0" release, but it targets "rhacm-2.5" instead

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

In response to this:

/bugzilla refresh

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.

@mkowalski
Copy link
Contributor Author

/bugzilla refresh

@openshift-ci openshift-ci bot added bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. and removed bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Oct 1, 2021
@openshift-ci
Copy link

openshift-ci bot commented Oct 1, 2021

@mkowalski: This pull request references Bugzilla bug 2007106, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (rhacm-2.5) matches configured target release for branch (rhacm-2.5)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

Requesting review from QA contact:
/cc @bjacot

In response to this:

/bugzilla refresh

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 openshift-ci bot requested a review from bjacot October 1, 2021 13:17
@mkowalski
Copy link
Contributor Author

mkowalski commented Oct 1, 2021

/cherry-pick ocm-2.4

2009759 is the backport BZ
2009760 is the 2nd backport BZ

@openshift-cherrypick-robot

@mkowalski: once the present PR merges, I will cherry-pick it on top of ocm-2.4 in a new PR and assign it to you.

In response to this:

/cherry-pick ocm-2.4

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.

@mkowalski
Copy link
Contributor Author

/test ?

@openshift-ci
Copy link

openshift-ci bot commented Oct 1, 2021

@mkowalski: The following commands are available to trigger required jobs:

  • /test ci-index
  • /test e2e-metal-assisted
  • /test e2e-metal-assisted-kube-api
  • /test e2e-metal-assisted-multi-version
  • /test e2e-metal-assisted-operator-ztp
  • /test images
  • /test lint
  • /test subsystem-aws
  • /test subsystem-kubeapi-aws

The following commands are available to trigger optional jobs:

  • /test e2e-ai-operator-ztp-ipv4v6-3masters-ocp-48
  • /test e2e-ai-operator-ztp-ipv4v6-3masters-ocp-49
  • /test e2e-ai-operator-ztp-ipv4v6-sno-ocp-48
  • /test e2e-ai-operator-ztp-ipv4v6-sno-ocp-49
  • /test e2e-metal-assisted-ipv6
  • /test e2e-metal-assisted-kube-api-late-binding-single-node
  • /test e2e-metal-assisted-networking
  • /test e2e-metal-assisted-none
  • /test e2e-metal-assisted-olm
  • /test e2e-metal-assisted-operator-disconnected
  • /test e2e-metal-assisted-operator-ztp-multinode-spoke
  • /test e2e-metal-assisted-single-node

Use /test all to run the following jobs that were automatically triggered:

  • pull-ci-openshift-assisted-service-master-ci-index
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted-kube-api
  • pull-ci-openshift-assisted-service-master-e2e-metal-assisted-operator-ztp
  • pull-ci-openshift-assisted-service-master-images
  • pull-ci-openshift-assisted-service-master-lint
  • pull-ci-openshift-assisted-service-master-subsystem-aws
  • pull-ci-openshift-assisted-service-master-subsystem-kubeapi-aws

In response to this:

/test ?

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.

@mkowalski
Copy link
Contributor Author

/test e2e-ai-operator-ztp-ipv4v6-3masters-ocp-48
/test e2e-ai-operator-ztp-ipv4v6-3masters-ocp-49
/test e2e-ai-operator-ztp-ipv4v6-sno-ocp-48
/test e2e-ai-operator-ztp-ipv4v6-sno-ocp-49

Copy link
Member

@djzager djzager left a comment

Choose a reason for hiding this comment

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

Looks good to me. Saving the lgtm label until we chat about the few comments.

return errors.Errorf("First machine network has to be IPv4 subnet")
}
if !IsIPv6CIDR(string(networks[1].Cidr)) {
return errors.Errorf("Second machine network has to be IPv6 subnet")
Copy link
Member

Choose a reason for hiding this comment

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

Have we given any thought to creating custom error types?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Never thought about this honestly. How would that look like ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I may be missing something from @djzager's idea but, considering that we don't check the type of any of these errors, I'm unsure how much value custom error types would bring. Perhaps reduce duplication of error messages? Could we use constants for some those?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd keep those ones as they are. The strings are only for humans to read them, we don't automate anything based on errors and based on my previous experience, it may happen that we start changing those messages very soon based on the users' understanding of them

Copy link
Member

Choose a reason for hiding this comment

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

More of a curiosity question than trying to ask for a change.

The only thing that stands out to me as a con to using errors.Errorf was that all of our tests are just looking for some hardcoded string. The pro I've experienced is that it makes it easy to find where a failure is coming from when the strings are hardcoded this way 😎 .

This can be resolved.

return nil
}

func ValidateDualStackNetworks(clusterParams interface{}) error {
Copy link
Member

Choose a reason for hiding this comment

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

Does this need to be public/exported?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, it does not need. It's only like this because other validators in this file are also public even if they are used only in this package. Do you prefer to make this one private or to have them all the same ?

Copy link
Member

Choose a reason for hiding this comment

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

Generally code is easier to maintain when there is less exporting, so I would go that direction. It's very easy to come back later and export it if/when the need arises.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @mhrivnak and @djzager here. Let's make an attempt to default to private as much as possible.

I would even be ok with a follow-up PR (that won't be backported) that makes the rest of these functions private (for the sake of consistency). Although, I would also understand it if people would rather not do such a refactor :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

valid: false,
},
{
element: []*string{swag.String("1.2.5.0/24"), swag.String("1002:db8::/119"), swag.String("1.2.6.0/24"), swag.String("1.2.7.0/24")},
valid: true,
element: []*models.MachineNetwork{{Cidr: "1.2.5.0/24"}, {Cidr: "1002:db8::/119"}, {Cidr: "1.2.6.0/24"}, {Cidr: "1.2.7.0/24"}},
Copy link
Member

Choose a reason for hiding this comment

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

For me and others coming here later, it would be helpful to comment in some way why these are valid or invalid.

Is this one invalid because only two are allowed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Comment on lines 706 to 710
for _, t := range tests {
t := t
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
for _, t := range tests {
t := t
for _, test := range tests {
t := test

I'm surprised with all the linting checks for shadowing that this is allowed. A little nitpicky but I think we should avoid this if we can.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As previously, I see this pattern in 5 different tests in this file. Do we want to change it in here or follow the current style ? (cc @flaper87)

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we can change this here but definitely let's not change all the cases like this in the file. Let's keep the backport as small as possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

This commit extends the validations performed for dual-stack OCP
clusters by making sure the following requirements are met if a cluster
is dual-stack

* exactly 2 machine networks are provided (if any)
* exactly 2 service networks are provided
* exactly 2 cluster networks are provided
* for every list containing 2 networks, the first one has to be IPv4 and
  the second one IPv6

Closes-bug: #2007106
Contributes-to: #2005440
Closes: OCPBUGSM-35447
Contributes-to: OCPBUGSM-35273
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 4, 2021
@openshift-ci
Copy link

openshift-ci bot commented Oct 4, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: djzager, mkowalski

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

openshift-ci bot commented Oct 4, 2021

@mkowalski: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-metal-assisted-networking ebd58a1 link false /test e2e-metal-assisted-networking
ci/prow/e2e-ai-operator-ztp-ipv4v6-3masters-ocp-49 cb23224 link false /test e2e-ai-operator-ztp-ipv4v6-3masters-ocp-49
ci/prow/e2e-ai-operator-ztp-ipv4v6-sno-ocp-49 cb23224 link false /test e2e-ai-operator-ztp-ipv4v6-sno-ocp-49

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

@mkowalski
Copy link
Contributor Author

/retest-required

@openshift-merge-robot openshift-merge-robot merged commit e757792 into openshift:master Oct 4, 2021
@openshift-ci
Copy link

openshift-ci bot commented Oct 4, 2021

@mkowalski: All pull requests linked via external trackers have merged:

Bugzilla bug 2007106 has been moved to the MODIFIED state.

In response to this:

Bug 2007106: Extend dual-stack network subnet validations

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-cherrypick-robot

@mkowalski: cannot checkout ocm-2.4: error checking out ocm-2.4: exit status 1. output: error: pathspec 'ocm-2.4' did not match any file(s) known to git

In response to this:

/cherry-pick ocm-2.4

2009759 is the backport BZ
2009760 is the 2nd backport BZ

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.

@mkowalski mkowalski deleted the bz2007106 branch October 4, 2021 19:38
@mkowalski
Copy link
Contributor Author

/cherry-pick release-ocm-2.4

2009759 is the backport BZ
2009760 is the 2nd backport BZ

@openshift-cherrypick-robot

@mkowalski: new pull request created: #2704

In response to this:

/cherry-pick release-ocm-2.4

2009759 is the backport BZ
2009760 is the 2nd backport BZ

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.

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. bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants