add the ability to attach to a running container. the tunnel side of this is not enabled yet as we have work on the endpoints and plumbing to do yet.
add the ability to exec a command in a running container. the tunnel side is also being deferred for same reason.
Signed-off-by: Brent Baude <bbaude@redhat.com>
create a container in podmanv2 using specgen approach. this is the core implementation and still has quite a bit of code commented out specifically around volumes, devices, and namespaces. need contributions from smes on these parts.
Signed-off-by: Brent Baude <bbaude@redhat.com>
this is only for the abi side and does not print out the remote information yet. the remote information will need to be worked on and agreed upon later.
Signed-off-by: Brent Baude <bbaude@redhat.com>
* Implement `podman-push` and `podman-image-push` for the podmanV2
client.
* Tests for `pkg/bindings` are not possible at the time of writing as we
don't have a local registry running.
* Implement `/images/{name}/push` compat endpoint. Tests are not
implemented for this v2 endpoint. It has been tested manually.
General note: The auth config extraction from the http header is not
implement for push. Since it's not yet supported for other endpoints
either, I deferred it to future work.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Instead of getting mount options from /proc/self/mountinfo, which is
very costly to read/parse (and can even be unreliable), let's use
statfs(2) to figure out the flags we need.
[v2: move getting default options to pkg/util, make it linux-specific]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We need to consistently use --time rather then --timeout throughout the code.
Fix locations where timeout defaults are not set correctly as well.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Implement pulling images for the v2 client. What I _really_ don't like
is the fact that we are now having a near identical code clone among
`pkg/domain/infra/abi` and `pkg/api/handlers/libpod`. Partly because we
don't yet have a higher-level pull function and partly because we have
redudancy among `pkg/domain` and `pkg/api`. Pull might be a high
outlier but I am concerned already by the potential of introducing more
redundancy. I'd love to `infra/abi` and `pkg/abi` to really use the
same code in the future.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
> $ ./bin/podman run -v /tmp:/tmp alpine true; echo $?
> 0
> $ ./bin/podman run -v /tmp:/tmp:ro alpine true; echo $?
> 0
> $ ./bin/podman run -v /tmp:/w0w:ro alpine true; echo $?
> Error: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/tmp\\\" to rootfs \\\"/home/kir/.local/share/containers/storage/overlay/7636ef3650fc91ee4996ccc026532bb3cff7182c0430db662fffb933e0bcadc9/merged\\\" at \\\"/home/kir/.local/share/containers/storage/overlay/7636ef3650fc91ee4996ccc026532bb3cff7182c0430db662fffb933e0bcadc9/merged/w0w\\\" caused \\\"operation not permitted\\\"\"": OCI runtime permission denied error
> 126
The last command is not working because in-container mount point
is used to search for a parent mount in /proc/self/mountinfo.
And yet the following
> $ ./bin/podman run -v /tmp:/run/test:ro alpine true; echo $?
> 0
still works fine! Here's why:
> $ mount | grep -E '/run |/tmp '
> tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
> tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel)
This is the reason why previous commit modified in-container mount
point.
Fixes: 0f5ae3c5af
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Note that this commit does not add tests for the pod-top endpoint.
They will be added in a later change.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The logic used in parsing the ports to be utilized in a kubenetes api
defined pod did not fully adhere to the kubenetes spec, nor did it map
well to a podman context. This fix sanitizes the input of container
ports to meet the following rules:
- A defined containerPort with no defined hostPort does nothing in a
podman context, or is informational. This is line with [usage in
Kubernetes.](https://github.com/kubernetes/kubernetes/issues/4332)
- A defined hostPort with no defined containerPort acts like a
publish [hostPort]:[hostPort]
- A defined containerPort and defined hostPort works like it does in
kubernetes, as in a publish [hostPort]:[containerPort]
Addresses https://github.com/containers/libpod/issues/5610
Signed-off-by: Tyler Ramer <tyaramer@gmail.com>
using the factory approach similar to container, we now create pods based on a pod spec generator. wired up the podmanv2 pod create command, podcreatewithspec binding, simple binding test, and apiv2 endpoint.
also included some code refactoring as it introduced as easy circular import.
Signed-off-by: Brent Baude <bbaude@redhat.com>
