Cleanup of tripleo services

[jpodivin]

Creates dataplane service 'tripleo-cleanup' which stops, disables
and finally removes unit files of tripleo systemd services.

The step is executed as last during dataplane adoption.

Depends-On: openstack-k8s-operators/edpm-ansible#649

[jpodivin]

recheck

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://review.rdoproject.org/zuul/buildset/881f7f38d9864d218fa84effc61bab62

❌ data-plane-adoption-osp-17-to-extracted-crc FAILURE in 2h 25m 31s
❌ data-plane-adoption-osp-17-to-extracted-crc-minimal-no-ceph FAILURE in 2h 18m 00s

[jpodivin]

recheck

[gibizer]

recheck

• there is newer versions of the dependency to check
• in the last CI run there was a failed job execution trial and only the second run of the playbook passed.

�[0;31mfailed: [standalone] (item=tripleo_neutron_l3_agent.service) => {�[0m
�[0;31m    "ansible_loop_var": "item",�[0m
�[0;31m    "changed": false,�[0m
�[0;31m    "invocation": {�[0m
�[0;31m        "module_args": {�[0m
�[0;31m            "daemon_reexec": false,�[0m
�[0;31m            "daemon_reload": false,�[0m
�[0;31m            "enabled": false,�[0m
�[0;31m            "force": null,�[0m
�[0;31m            "masked": true,�[0m
�[0;31m            "name": "tripleo_neutron_l3_agent.service",�[0m
�[0;31m            "no_block": false,�[0m
�[0;31m            "scope": "system",�[0m
�[0;31m            "state": "stopped"�[0m
�[0;31m        }�[0m
�[0;31m    },�[0m
�[0;31m    "item": "tripleo_neutron_l3_agent.service",�[0m
�[0;31m    "msg": "Could not find the requested service tripleo_neutron_l3_agent.service: host"�[0m

[fao89]

I wonder if we should have it in the dataplane-operator repo

[gibizer]

We have priory art defining adoption specific service on the fly in the data-plane-adoption repo. The pre-adoption-validation service is defined in the same way.

[gibizer]

There is still a retry of tripleo-cleanup playbook in the CI job https://logserver.rdoproject.org/38/438/117d7f34837e55ceefefbf6514fa08c2445fc1a9/github-check/data-plane-adoption-osp-17-to-extracted-crc-minimal-no-ceph/1f3ca9b/controller/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/pods/

the first fails with:
https://logserver.rdoproject.org/38/438/117d7f34837e55ceefefbf6514fa08c2445fc1a9/github-check/data-plane-adoption-osp-17-to-extracted-crc-minimal-no-ceph/1f3ca9b/controller/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/pods/tripleo-cleanup-tripleo-cleanup-openstack-527h6/logs/openstackansibleee.log

�[0;31mfailed: [standalone] (item=tripleo_neutron_l3_agent.service) => {�[0m
�[0;31m    "ansible_loop_var": "item",�[0m
�[0;31m    "changed": false,�[0m
�[0;31m    "invocation": {�[0m
�[0;31m        "module_args": {�[0m
�[0;31m            "daemon_reexec": false,�[0m
�[0;31m            "daemon_reload": false,�[0m
�[0;31m            "enabled": false,�[0m
�[0;31m            "force": null,�[0m
�[0;31m            "masked": true,�[0m
�[0;31m            "name": "tripleo_neutron_l3_agent.service",�[0m
�[0;31m            "no_block": false,�[0m
�[0;31m            "scope": "system",�[0m
�[0;31m            "state": "stopped"�[0m
�[0;31m        }�[0m
�[0;31m    },�[0m
�[0;31m    "item": "tripleo_neutron_l3_agent.service",�[0m
�[0;31m    "msg": "Could not find the requested service tripleo_neutron_l3_agent.service: host"�[0m
�[0;31m}�[0m

the the second try of the playbook succeeds:
https://logserver.rdoproject.org/38/438/117d7f34837e55ceefefbf6514fa08c2445fc1a9/github-check/data-plane-adoption-osp-17-to-extracted-crc-minimal-no-ceph/1f3ca9b/controller/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/pods/tripleo-cleanup-tripleo-cleanup-openstack-6nzph/logs/openstackansibleee.log

[jpodivin]

It's two services tripleo_neutron_ovs_agent and tripleo_neutron_l3_agent that are apparently not available when ansible tries to manage them. It is odd, because we are getting list of existing services by service_facts module. This should be fine, since it uses systemctl under the hood.

There may be way to get rid of the not-found status, if we reload everything before executing the primary task.

[jpodivin]

recheck

[softwarefactory-project-zuul]

This change depends on a change that failed to merge.

Change openstack-k8s-operators/edpm-ansible#649 is needed.

[jpodivin]

recheck