Expose Podman connection creation over existing SSH client connection

[partiallyordered]

This enables creation of a Podman connection from a pre-existing SSH connection, avoiding the creation of a new SSH connection when one already exists, or writing the private key to the file system so it can be found by the connection mechanism.

Motivation: I'm writing some developer tools and automation and I'd prefer not to put the relevant identity into the file system, primarily for security reasons but also for simplicity (I already have it in memory). This seemed a sensible means of achieving such an objective but I can see some alternatives:

• Supply the identity as an X509 string (or similar) and try to parse it as such in the NewConnectionWithIdentity function
• Create a NewConnectionFromConnection (which could perhaps be better named) to which the user can supply a bindings.Connection object they've constructed and have it placed on the resulting context

In any case, I also couldn't easily see how tests for this would easily fit into the existing tests (I couldn't obviously see what the existing tests were doing and where to put a new test- this is probably my fault) and thought I'd submit the PR here for

1. some guidance as to how to test it and
2. an indication whether this could be accepted into the project (i.e. would I be wasting everyone's time proceeding with this PR)

Finally, I've entered None for release notes because I don't know whether a non-breaking change to the bindings necessitates release notes (and I can't tell for sure by looking at the last few releases).

Thanks for your time and consideration.

Does this PR introduce a user-facing change?

None

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: partiallyordered Once this PR has been reviewed and has the lgtm label, please assign ashley-cui for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service[bot]]

Ephemeral COPR build failed. @containers/packit-build please check.

[packit-as-a-service[bot]]

We were not able to find or create Copr project packit/containers-podman-21752 specified in the config with the following error:

Packit received HTTP 500 Internal Server Error from Copr Service. Check the Copr status page: https://copr.fedorainfracloud.org/status/stats/, or ask for help in Fedora Build System matrix channel: https://matrix.to/#/#buildsys:fedoraproject.org.

---

Unless the HTTP status code above is >= 500, please check your configuration for:

1. typos in owner and project name (groups need to be prefixed with @)
2. whether the project name doesn't contain not allowed characters (only letters, digits, underscores, dashes and dots must be used)
3. whether the project itself exists (Packit creates projects only in its own namespace)
4. whether Packit is allowed to build in your Copr project
5. whether your Copr project/group is not private

[packit-as-a-service[bot]]

Ephemeral COPR build failed. @containers/packit-build please check.

[lsm5]

@partiallyordered thanks for the PR. rpm build jobs are failing with:

go: inconsistent vendoring in /builddir/build/BUILD/podman-5.3.0_dev-build/podman-5.3.0-dev:
	github.com/stretchr/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	gopkg.in/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	k8s.io/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/bytedance/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/chenzhuoyu/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/kr/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/rivo/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/yusufpapurcu/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	go.mongodb.org/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
	github.com/bytedance/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
	github.com/chenzhuoyu/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
	github.com/rivo/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
	github.com/stretchr/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
	github.com/yusufpapurcu/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
	go.mongodb.org/[email protected]: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod

	To ignore the vendor directory, use -mod=readonly or -mod=mod.
	To sync the vendor directory, run:
		go mod vendor
error: Bad exit status from /var/tmp/rpm-tmp.J6OKwt (%build)

You'll need to run make vendor and commit all the files added to the vendor/ dir.

@mheon @Luap99 PTAL

[partiallyordered]

@lsm5 thanks for the response. Actually, I no longer recall whether I needed to change go.mod at all. It seems quite unlikely. I've updated the PR to remove those changes; it looks like rpm builds are okay now. Let me know what else I can do to help.

[packit-as-a-service[bot]]

Cockpit tests failed for commit 2c636c710bc45fd22e8c24c838dded9b25a82aa0. @martinpitt, @jelly, @mvollmer please check.

[partiallyordered]

Cockpit tests failed for commit 2c636c7. @martinpitt, @jelly, @mvollmer please check.

Looks like this is the cause, linked here though as I'm unfamiliar with the tests I'm not sure if that's the root cause or otherwise. Nor whether I'm correct in assuming that's a test environment setup failure.

/ # Traceback (most recent call last):
  File "/source/test/check-application", line 1524, in testCheckpointRestore
    b.wait(lambda: self.getContainerAttr("swamped-crate", "State") in NOT_RUNNING)
  File "/source/test/common/testlib.py", line 757, in wait
    raise Error('timed out waiting for predicate to become true')
testlib.Error: timed out waiting for predicate to become true

[jelly]

Cockpit tests failed for commit 2c636c7. @martinpitt, @jelly, @mvollmer please check.

Looks like this is the cause, linked here though as I'm unfamiliar with the tests I'm not sure if that's the root cause or otherwise. Nor whether I'm correct in assuming that's a test environment setup failure.

/ # Traceback (most recent call last):
  File "/source/test/check-application", line 1524, in testCheckpointRestore
    b.wait(lambda: self.getContainerAttr("swamped-crate", "State") in NOT_RUNNING)
  File "/source/test/common/testlib.py", line 757, in wait
    raise Error('timed out waiting for predicate to become true')
testlib.Error: timed out waiting for predicate to become true

This might be a test flake if it still occurs after a retry I'm happy to take a look

[partiallyordered]

@jelly thanks. I wondered the same. How do I trigger a retry?

[martinpitt]

@partiallyordered Click on the "Details.." link of the failed test. That gets you here, where project members have a "Re-run" link button next to the failed test (in the left menu bar). I can't do that.

[partiallyordered]

@martinpitt thank you, well, either I'm missing something, or nor can I trigger a retry.

[lsm5]

i've triggered a rerun of the test just now.

[lsm5]

Guess this change would need an associated test. @mheon @baude @Luap99 PTAL.