refactor(vuln): use database-upgrade entrypoint opt

[vkrizan]

No description provided.

[vkrizan]

cc @ehelms

[vkrizan]

Tests blocked on #18

[ehelms]

I moved the upgrade out to a oneshot service (https://github.com/ehelms/puppet-iop/blob/master/manifests/service_vulnerability.pp#L60). If you rebase this and modify it there I think it will pass.

[vkrizan]

Rebased

[ehelms]

The rebase is changing more than it needs to:

diff --git a/manifests/service_vulnerability.pp b/manifests/service_vulnerability.pp
index 41cbbbc..6366f5f 100644
--- a/manifests/service_vulnerability.pp
+++ b/manifests/service_vulnerability.pp
@@ -78,7 +78,7 @@ class iop::service_vulnerability (
         'Image'         => $image,
         'ContainerName' => 'iop-service-vuln-dbupgrade',
         'Network'       => 'iop-core-network',
-        'Exec'          => 'bash -c /engine/dbupgrade.sh',
+        'Exec'          => '/engine/entrypoint.sh database-upgrade',
         'Volume'        => [
           '/var/run/postgresql:/var/run/postgresql:rw',
         ],

[vkrizan]

@ehelms the point of this is to drop the oneoff container in favor of handling db upgrades in entrypoint.

[ehelms]

I think the problem is that the vuln-manager service is starting but does not wait to signal running and thus execution continues of the other services. I think we would have to ensure sdnotify support to do this dependency chaining at the systemd level. I will try it at the puppet level.

[vkrizan]

@ehelms We can technically utilize health status of pods, which podman supports. I wanted to look into it closer, whether systemd can adopt health status of an underlying container.

[ehelms]

I think for now we do one of the following:

1. Update the migrate service exec to use the new command
2. Leave this code alone, put this into draft PR for now and revisit when we have time

[vkrizan]

@ehelms Switched to draft. I think we need to have this figured out before there would be any new database migrations within the service required to be applied, as this standalone migration application is a one-off.

I think the problem is that the vuln-manager service is starting but does not wait to signal running and thus execution continues of the other services.

Is that an issue for the FDW setup?

[ehelms]

Is that an issue for the FDW setup?

Does not appear to be so.