setup / reload fails on brand new VM

[hash-d]

Running a playbook that uses the skupper.v2.system action setup (2.0) or reload (2.1) on a brand new VM fails silently.

2.0:

TASK [Start it] ***************************************************************************************************************************************************************************************************
task path: /tmp/test/asdf.yaml:12                   
[WARNING]: error writing service file '/home/cloud-user/.config/systemd/user/skupper-asdf.service': [Errno 2] No such file or directory: '/home/cloud-user/.config/systemd/user/skupper-asdf.service'
changed: [localhost] => {"changed": true, "gid": 1000, "group": "cloud-user", "links": {}, "mode": "0755", "owner": "cloud-user", "path": "/home/cloud-user/.local/share/skupper/namespaces/asdf", "secontext": "unconfined_u:object_r:container_file_t:s0", "size": 50, "state": "directory", "uid": 1000}           

2.1:

TASK [Start it] ***************************************************************************************************************************************************************************************************
[WARNING]: error writing service file '/home/cloud-user/.config/systemd/user/skupper-asdf.service': [Errno 2] No such file or directory: '/home/cloud-user/.config/systemd/user/skupper-asdf.service'
changed: [localhost]

In both cases, the warning is logged, but the actual task is reported as changed, which is a successful state.

The issue was detected while running the Integration tests on 2.0, where it fails on the test Assert that the systemd service exists.

I'm not sure why, the 2.1 tests pass, despite the problem existing on that branch as well.

As far as the testing is concerned, the issue is easily bypassed by issuing the command below:

$ mkdir -p ~/.config/systemd/user/

However, for an actual user setting up a brand new server this would be more than a nuissance.

[hash-d]

Reproducers

2.0

- name: asdf
  hosts: localhost
  gather_facts: no
  tasks:
  - name: Create resources
    skupper.v2.resource:
      path: site.yaml
      namespace: asdf
      platform: podman
  - name: Start it
    skupper.v2.system:
      action: setup
      namespace: asdf
  - name: Teardown
    skupper.v2.system:
      action: teardown
      namespace: asdf

2.1

- name: asdf
  hosts: localhost
  gather_facts: no
  tasks:
  - name: Create resources
    skupper.v2.resource:
      path: site.yaml
      namespace: asdf
      platform: podman
  - name: Start it
    skupper.v2.system:
      action: reload
      namespace: asdf
  - name: Teardown
    skupper.v2.system:
      action: stop
      namespace: asdf

Common (site.yaml)

apiVersion: skupper.io/v2alpha1
kind: Site
metadata:
  name: asdf

[hash-d]

Notice that in both versions, the teardown / stop action also has similar, incorrect behavior:

TASK [Teardown] ***************************************************************************************************************************************************************************************************
task path: /tmp/test/asdf.yaml:19                                                                                                                                                                                  
[WARNING]: SystemD service has not been defined: /home/cloud-user/.config/systemd/user/skupper-asdf.service                                                                                                        
[WARNING]: error stopping service 'skupper-asdf.service': Failed to disable unit: Unit file skupper-asdf.service does not exist.
[WARNING]: error removing service file '/home/cloud-user/.config/systemd/user/skupper-asdf.service': [Errno 2] No such file or directory: '/home/cloud-user/.config/systemd/user/skupper-asdf.service'
changed: [localhost] => {"changed": true, "path": "/home/cloud-user/.local/share/skupper/namespaces/asdf"}

(silent failure)