kube play: support auto updates and rollbacks

Add auto-update support to `podman kube play`.  Auto-update policies can
be configured for:
 * the entire pod via the `io.containers.autoupdate` annotation
 * a specific container via the `io.containers.autoupdate/$name` annotation

To make use of rollbacks, the `io.containers.sdnotify` policy should be
set to `container` such that the workload running _inside_ the container
can send the READY message via the NOTIFY_SOCKET once ready.  For
further details on auto updates and rollbacks, please refer to the
specific article [1].

Since auto updates and rollbacks bases on Podman's systemd integration,
the k8s YAML must be executed in the `podman-kube@` systemd template.
For further details on how to run k8s YAML in systemd via Podman, please
refer to the specific article [2].

An examplary k8s YAML may look as follows:
```YAML
apiVersion: v1
kind: Pod
metadata:
  annotations:
      io.containers.autoupdate: "local"
      io.containers.autoupdate/b: "registry"
  labels:
    app: test
  name: test_pod
spec:
  containers:
  - command:
    - top
    image: alpine
    name: a
  - command:
    - top
    image: alpine
    name: b
```

[1] https://www.redhat.com/sysadmin/podman-auto-updates-rollbacks
[2] https://www.redhat.com/sysadmin/kubernetes-workloads-podman-systemd

Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>

1 files changed, 15 insertions, 14 deletions

diff --git a/test/system/250-systemd.bats b/test/system/250-systemd.bats
index 8f4471f91..dd1a0f05a 100644
--- a/test/system/250-systemd.bats
+++ b/test/system/250-systemd.bats
@@ -301,24 +301,16 @@ LISTEN_FDNAMES=listen_fdnames" | sort)
 }
 
 @test "podman-kube@.service template" {
-    # If running from a podman source directory, build and use the source
-    # version of the play-kube-@ unit file
-    unit_name="podman-kube@.service"
-    unit_file="contrib/systemd/system/${unit_name}"
-    if [[ -e ${unit_file}.in ]]; then
-        echo "# [Building & using $unit_name from source]" >&3
-        # Force regenerating unit file (existing one may have /usr/bin path)
-        rm -f $unit_file
-        BINDIR=$(dirname $PODMAN) make $unit_file
-        cp $unit_file $UNIT_DIR/$unit_name
-    fi
-
+    install_kube_template
     # Create the YAMl file
     yaml_source="$PODMAN_TMPDIR/test.yaml"
     cat >$yaml_source <<EOF
 apiVersion: v1
 kind: Pod
 metadata:
+  annotations:
+      io.containers.autoupdate: "local"
+      io.containers.autoupdate/b: "registry"
   labels:
     app: test
   name: test_pod
@@ -327,8 +319,11 @@ spec:
   - command:
     - top
     image: $IMAGE
-    name: test
-    resources: {}
+    name: a
+  - command:
+    - top
+    image: $IMAGE
+    name: b
 EOF
 
     # Dispatch the YAML file
@@ -349,6 +344,12 @@ EOF
     run_podman 125 container rm $service_container
     is "$output" "Error: container .* is the service container of pod(s) .* and cannot be removed without removing the pod(s)"
 
+    # Add a simple `auto-update --dry-run` test here to avoid too much redundancy
+    # with 255-auto-update.bats
+    run_podman auto-update --dry-run --format "{{.Unit}},{{.Container}},{{.Image}},{{.Updated}},{{.Policy}}"
+    is "$output" ".*$service_name,.* (test_pod-a),$IMAGE,false,local.*" "global auto-update policy gets applied"
+    is "$output" ".*$service_name,.* (test_pod-b),$IMAGE,false,registry.*" "container-specified auto-update policy gets applied"
+
     # Kill the pod and make sure the service is not running.
     # The restart policy is set to "never" since there is no
     # design yet for propagating exit codes up to the service