network: respect pre-set API_VIPS and INGRESS_VIPS

[bogdando]

When API_VIPS and INGRESS_VIPS are already set in the environment (e.g. via config_$USER.sh), skip the dig lookups and dnsmasq reconfiguration in set_api_and_ingress_vip().

This is needed for bare-metal deployments where dnsmasq is not yet running when network.sh executes, causing the dig lookups to fail and leaving the VIPs empty in install-config.yaml.

Generated-By: Cursor (claude-4.6-opus-high)

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign andfasano for approval. For more information see the 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-ci]

Hi @bogdando. Thanks for your PR.

I'm waiting for a openshift-metal3 member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[bogdando]

ftr, I needed this fix in https://github.com/openstack-k8s-operators/ci-framework/pull/3739/changes#diff-b42c1ffd0e6c247d43022ea34bad373ac33b9135425cd21e87549d0b0196d629R54 for our specific BM SNO setup in RHOSO

[cybertron]

This won't work for virt environments, so I think the logic should be moved into the baremetal-specific code path.

I'm also curious how these records are being configured. Normally in a baremetal cluster the API and ingress records are created in the upstream DNS server prior to creating the cluster. Presumably that's not being done in this test environment. Is there a reason for that?

[bogdando]

This won't work for virt environments, so I think the logic should be moved into the baremetal-specific code path.

Thanks, I will double check on my test env (that hack had surely helped to solve the issues with the bottstrap VM and BM target OCP SNO host)

I'm also curious how these records are being configured. Normally in a baremetal cluster the API and ingress records are created in the upstream DNS server prior to creating the cluster. Presumably that's not being done in this test environment. Is there a reason for that?

I am trying a setup where api and ingress records are non routable addresses in the /etc/hosts, and being reached via DNAT rules on the CI controller into bootstrap VM so that virtual media traffic can traverse both directions - to the iDRAC and back to Ironic