Description of problem (please be detailed as possible and provide log
snippests):

We've been debugging an issue with networking to external ceph and we figured out that enabling ceph tools via `OSCInitialization` creates a rook-ceph-tools pod with completely different network settings than it is applied to rook-ceph-operator


Version of all relevant components (if applicable): 4.10.6 ODF on OCP 4.10.26


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?

Partially, options for debugging networking issues are limited. 


Is there any workaround available to the best of your knowledge?

Use rook-ceph-operator directly for remote shell instead of rook-ceph-tools.


Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?


Can this issue reproducible?

Yes

Can this issue reproduce from the UI?

No

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. Install ODF in external mode
2. Deploy ceph tools via OSCInitialization
3. Compare Pod YAMLs


Actual results:

See attached Pod manifests to compare.

Tools pod has `.spec.hostNetwork: true` and `.spec.dnsPolicy: ClusterFirstWithHostNet` while operator pod has `.spec.dnsPolicy: ClusterFirst`. This leads to vastly different behavior when tools pod is able to use host routing table while operator can't.

Expected results:

Network setting matches

Additional info:

Related to: https://bugzilla.redhat.com/show_bug.cgi?id=2129111