Support environment variable for choosing podman-remote connection

[afbjorklund]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

From #7602 (comment)

Description

Currently there is an environment variable for the --url, but nothing for the --connection

Flags:
  -c, --connection string         Connection to use for remote Podman service
  -r, --remote                    Access remote Podman service (default false)
      --url string                URL to access Podman service (CONTAINER_HOST) (default "unix:/run/user/1000/podman/podman.sock")

There could a $CONTAINER_NAME for setting the connection name,
similar to the current $CONTAINER_HOST for setting entire url ?

Currently it requires modifying the config, which is shared.

  podman system connection [command]

Available Commands:
  default     Set named destination as default

Or always using the --connection parameter, which is tedious.

Steps to reproduce the issue:

Describe the results you received:

Describe the results you expected:

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

Output of podman version:

Version:      2.0.6
API Version:  1
Go Version:   go1.14.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

(paste your output here)

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

Listing... Done
podman/unknown 2.0.6~2 amd64 [upgradable from: 2.0.6~1]
podman/unknown 2.0.6~2 arm64
podman/unknown 2.0.6~2 armhf
podman/unknown 2.0.6~2 s390x

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

Yes/No

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

[afbjorklund]

The workaround is to continue to use CONTAINER_HOST and CONTAINER_SSHKEY.

[rhatdan]

I would think CONTAINER_CONNECTION would be better then CONTAINER_NAME

[afbjorklund]

I was just going with CONTAINER_HOST vs CONTAINER_URL, but you are probably right.

The use case would be running in two shells at the same, towards different virtual machines.