containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.71k stars 2.41k forks source link

Quadlet: Can we infer volumes from containers in some cases? #16774

Closed mhjacks closed 1 year ago

mhjacks commented 1 year ago

/kind feature

Description

Currently, quadlet requires the creation of volume files to auto-create volume services for containers to depend on. However, in degenerate cases, the entire volume file might be: [Volume]

In a case where the UID/GID does not need to be set and there are no labels defined on the volume. Should

Steps to reproduce the issue:

  1. Create a .conftainer file in /etc/containers/systemd that requires a volume

  2. Declare the .volume file with simply [Volume]. Define a few more and mount them, if you're inclined

  3. Ponder whether there's a better way to specify volumes in such cases

Describe the results you received:

Declaration of volumes currently requires creating effectively empty files. This seems sub-optimal, though not a deal-breaker

Describe the results you expected:

What about declaring volumes in a separate section of the .container file? Or inferring them from the container file in some way?

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 4.4.0-dev

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.29.0-dev
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.5-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: 48adb81a22c26f0660f0f37d984baebe7b9ade98'
  cpuUtilization:
    idlePercent: 99.79
    systemPercent: 0.09
    userPercent: 0.12
  cpus: 2
  distribution:
    distribution: '"centos"'
    version: "9"
  eventLogger: journald
  hostname: srv-c9s-t.imladris.lan
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.14.0-202.el9.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 6064009216
  memTotal: 8330178560
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-0.0-20221130150914.2700598.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version UNKNOWN
      commit: 9c4a7e486dd957d7810d271c585ce4729dfe1da0
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-2.el9.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 2147479552
  swapTotal: 2147479552
  uptime: 23h 21m 41.00s (Approximately 0.96 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 18238930944
  graphRootUsed: 4628869120
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.4.0-dev
  Built: 0
  BuiltTime: Wed Dec 31 18:00:00 1969
  GitCommit: ""
  GoVersion: go1.18.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.4.0-dev

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman-0.0.git.17326.293f1cd1-1.el9.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

I really like the quadlet model of instantiating and starting containers. It's expressive and relatively compact (except for the volume files, if needed). I believe there are cases where volumes need to be supported for workloads - and it's a bit of a challenge to do so. To be clear the existing .volume files are not a dealbreaker - but the existing docs don't have examples and it's not especially clear when or how to use them (the original quadlet repo had a bug about adding .volume file examples). So I'm asking - do we need them at all? If there are cases where we definitely do need them, I think it's better to make it explicit (and do it the way we are doing it) than to have two ways of doing it and introduce those complexities

dustymabe commented 1 year ago

The .volume file isn't needed. If no volume exists it should be auto-created. For example if you have this in your .container file:

Volume=/var/foo

Then a local volume will get autocreated for you. Try it out and run podman volume ls to see.

mhjacks commented 1 year ago

Confirmed! This also works with arbitrary volume labels, which is really, really nice. Thanks