Update manilaapi to use service override

[stuggi]

Removes creation of routes.Those get done in the openstack-operator. Via service overrides the service can be customized. The service operator adds annotation to the service which needs to be exposed as a route.

Jira: OSP-26690

Depends-On: openstack-k8s-operators/lib-common#332

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stuggi

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:

• OWNERS [stuggi]

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

[stuggi]

/hold

[stuggi]

/test manila-operator-build-deploy-kuttl

[stuggi]

The issue we right now is that the we are building the new operator with the current version of the openstack-operator which has not the functionality to create the route for the new service operator version. With this the public endpoint will be a ClusterIP service and is not reachable by the tempest job which is running outside the OCP env.

I think we have two options:

• update the current samples in the openstack-operator for network-isolation (if that is used by tempest) to also use a LoadBalancer type service for the public endpoint and see if that works for the tempest job
• force merge with failed tempest job result until we merged the openstack-operator PR

[stuggi]

The issue we right now is that the we are building the new operator with the current version of the openstack-operator which has not the functionality to create the route for the new service operator version. With this the public endpoint will be a ClusterIP service and is not reachable by the tempest job which is running outside the OCP env.

I think we have two options:

• update the current samples in the openstack-operator for network-isolation (if that is used by tempest) to also use a LoadBalancer type service for the public endpoint and see if that works for the tempest job

This would only work if the host tempest is running is using our DNS server where the service endpoint gets registered

• force merge with failed tempest job result until we merged the openstack-operator PR

[openshift-ci]

@stuggi: The following test 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/manila-operator-build-deploy-tempest	e048f84	link	true	/test manila-operator-build-deploy-tempest

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.

[fmount]

The issue we right now is that the we are building the new operator with the current version of the openstack-operator which has not the functionality to create the route for the new service operator version. With this the public endpoint will be a ClusterIP service and is not reachable by the tempest job which is running outside the OCP env.
I think we have two options:

• update the current samples in the openstack-operator for network-isolation (if that is used by tempest) to also use a LoadBalancer type service for the public endpoint and see if that works for the tempest job

This would only work if the host tempest is running is using our DNS server where the service endpoint gets registered

• force merge with failed tempest job result until we merged the openstack-operator PR

I agree we should force-merge these patches and avoid growing the patch series to get the Routes creation moved at the openstack-operator level.
I'm going to force-merge this and work with @stuggi to land the whole patch chain, otherwise any other patch will be stuck failing in CI.