Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-22229

user linger needed before secrets

    • rhel-system-roles-1.23.0-2.18.el8
    • None
    • None
    • rhel-sst-system-roles
    • 23
    • 26
    • 2
    • QE ack, Dev ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • None
    • Bug Fix
    • Hide
      .The `podman` RHEL system role now sets and cancels linger properly for rootless containers

      Previously, the `podman` RHEL System Role did not set and cancel linger properly for rootless containers.
      Consequently, deploying secrets or containers for rootless users produced errors in some cases, and failed to cancel linger when removing resources in some cases.
      With this update, the `podman` RHEL System Role ensures that linger is enabled for rootless users before doing any secret or container resource management, and ensures that linger is canceled for rootless users when there are no more secrets or container resources to be managed.
      As a result, the role correctly manages lingering for rootless users.
      Show
      .The `podman` RHEL system role now sets and cancels linger properly for rootless containers Previously, the `podman` RHEL System Role did not set and cancel linger properly for rootless containers. Consequently, deploying secrets or containers for rootless users produced errors in some cases, and failed to cancel linger when removing resources in some cases. With this update, the `podman` RHEL System Role ensures that linger is enabled for rootless users before doing any secret or container resource management, and ensures that linger is canceled for rootless users when there are no more secrets or container resources to be managed. As a result, the role correctly manages lingering for rootless users.
    • Done
    • None

      The https://github.com/linux-system-roles/podman/blob/main/tasks/create_update_kube_spec.yml#L2 user lingering stuff needs to be done before creating any secrets for a rootless user, and needs to be removed when the last user secret is removed.

      For the creation, we can probably just copy the block of code and put it near the top of handle_secrets after we know the user.

      The removal is a bit tricky. We need to know when the last secret is removed, and we need to coordinate the linger removal with https://github.com/linux-system-roles/podman/blob/main/tasks/cleanup_kube_spec.yml#L50 and https://github.com/linux-system-roles/podman/blob/main/tasks/cleanup_quadlet_spec.yml#L75 - maybe something like this:

      ```
      main
      __podman_cancel_user_linger: {} # set of users to check if can cancel linger
      for secret in secrets
      handle_secret
      if rootless
      if removing
      __podman_cancel_user_linger[username] = true
      else
      if not lingering then enable lingering
      __podman_cancel_user_linger[username] = false # possibly deleted one secret and added another
      ```
      similar logic for kube specs and quadlets - set user to `true` or `false` in __podman_cancel_user_linger
      then, at the end of tasks/main.yml
      ```
      for username in __podman_cancel_user_linger.keys() if __podman_cancel_user_linger[username]
      get secrets for user
      if any secrets
      continue # try next user
      get containers for user
      if any containers
      continue
      get volumes for user
      if any volumes
      continue
      get networks for user
      if any networks
      continue

      1. if we got here, there are no resources in use for username
        cancel linger for username
        __podman_cancel_user_linger: {} # erase
        ```

              rmeggins@redhat.com Richard Megginson
              rmeggins@redhat.com Richard Megginson
              Richard Megginson Richard Megginson
              David Jez David Jez
              Gabriela Necasova Gabriela Necasova
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: