When we want to customize services deployed on EDPM nodes, we have the following two ways:

• Modify OpenStackDataPlaneNodeSet.spec.service
• Modify OpenStackDataPlaneDeployment.spec.servicesOverride

The following NFV document uses OpenStackDataPlaneDeployment.spec.servicesOverride:

• https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_a_network_functions_virtualization_environment/assembly_create-data-plane-sriov-dpdk_rhoso-nfv#proc_deploying-the-data-plane_dataplane

However, I don't like using OpenStackDataPlaneDeployment.spec.servicesOverride.
That's because, if we use OpenStackDataPlaneDeployment.spec.servicesOverride at the first deployment, all new OpenStackDataPlaneDeployment resources in Day-2 operations must have the same .spec.servicesOverride.
If we miss .spec.servicesOverride in a new OpenStackDataPlaneDeployment resource, EDPM nodes will lose SRIOV/DPDK settings.
I saw a customer who made this mistake.

Therefore, it should be better to use OpenStackDataPlaneNodeSet.spec.service than using OpenStackDataPlaneDeployment.spec.servicesOverride in the above NFV document.
If we modify OpenStackDataPlaneNodeSet.spec.service, OpenStackDataPlaneDeployment no longer needs .spec.servicesOverride and this kind of mis-operation will be prevented.