stackablectl experimental-debug

debug is an experimental preview command, and may be changed or removed at any time.

Launches and an ephemeral debug container in a Pod and then attaches to it.

The container will have access to the same data volumes and environment variables as the selected target container.

General Usage

EXPERIMENTAL: Launch a debug container for a Pod.

This container will have access to the same data volumes as the primary container.

Usage: stackablectl experimental-debug [OPTIONS] --container <CONTAINER> <POD> [-- <CMD>...]

Arguments:
  <POD>
          The Pod to debug

  [CMD]...
          The command to run in the debug container

Options:
  -l, --log-level <LOG_LEVEL>
          Log level this application uses

  -n, --namespace <NAMESPACE>
          The namespace of the Pod being debugged

  -c, --container <CONTAINER>
          The target container to debug

          Volumes and environment variables will be copied from this container.

      --no-cache
          Do not cache the remote (default) demo, stack and release files

          Cached files are saved at '$XDG_CACHE_HOME/stackablectl', which is usually
          '$HOME/.cache/stackablectl' when not explicitly set.

      --image <IMAGE>
          The debug container image

          Defaults to the image of the target container if not specified.

  -h, --help
          Print help (see a summary with '-h')

  -V, --version
          Print version

File options:
  -d, --demo-file <DEMO_FILE>
          Provide one or more additional (custom) demo file(s)

          Demos are loaded in the following order: Remote (default) demo file, custom
          demo files provided via the 'STACKABLE_DEMO_FILES' environment variable, and
          lastly demo files provided via the '-d/--demo-file' argument(s). If there are
          demos with the same name, the last demo definition will be used.

          Use "stackablectl [OPTIONS] <COMMAND> -d path/to/demos1.yaml -d path/to/demos2.yaml"
          to provide multiple additional demo files.

  -s, --stack-file <STACK_FILE>
          Provide one or more additional (custom) stack file(s)

          Stacks are loaded in the following order: Remote (default) stack file, custom
          stack files provided via the 'STACKABLE_STACK_FILES' environment variable, and
          lastly demo files provided via the '-s/--stack-file' argument(s). If there are
          stacks with the same name, the last stack definition will be used.

          Use "stackablectl [OPTIONS] <COMMAND> -s path/to/stacks1.yaml -s path/to/stacks2.yaml"
          to provide multiple additional stack files.

  -r, --release-file <RELEASE_FILE>
          Provide one or more additional (custom) release file(s)

          Releases are loaded in the following order: Remote (default) release file,
          custom release files provided via the 'STACKABLE_RELEASE_FILES' environment
          variable, and lastly release files provided via the '-r/--release-file'
          argument(s). If there are releases with the same name, the last release
          definition will be used.

          Use "stackablectl [OPTIONS] <COMMAND> -r path/to/releases1.yaml -r path/to/releases2.yaml"
          to provide multiple additional release files.

Helm repository options:
      --helm-repo-stable <URL>
          Provide a custom Helm stable repository URL

          [default: https://repo.stackable.tech/repository/helm-stable/]

      --helm-repo-test <URL>
          Provide a custom Helm test repository URL

          [default: https://repo.stackable.tech/repository/helm-test/]

      --helm-repo-dev <URL>
          Provide a custom Helm dev repository URL

          [default: https://repo.stackable.tech/repository/helm-dev/]