| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The usual flow for exec is going to be:
- Create exec session
- Start and attach to exec session
- Exec session exits, attach session terminates
- Client does an exec inspect to pick up exit code
The safest point to remove the exec session, without doing any
database changes to track stale sessions, is to remove during the
last part of this - the single inspect after the exec session
exits.
This is definitely different from Docker (which would retain the
exec session for up to 10 minutes after it exits, where we will
immediately discard) but should be close enough to be not
noticeable in regular usage.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
| |
We can't save the exec session, but it's because the container
is entirely gone, so no point erroring.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
If not overridden, we should use the attach configuration given
when the exec session was first created.
Also, setting streams should not conflict with a TTY - the two
are allowed together with Attach and should be allowed together
here.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is heavily based off the existing exec implementation, but
does not presently share code with it, to try and ensure we don't
break anything.
Still to do:
- Add code sharing with existing exec implementation
- Wire in the frontend (exec HTTP endpoint)
- Move all exec-related code in oci_conmon_linux.go into a new
file
- Investigate code sharing between HTTP attach and HTTP exec.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
| |
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>
|
| |\
| |
| | |
Implement APIv2 Exec Create and Inspect Endpoints
|
| | |
| |
| |
| |
| |
| |
| | |
Also adds some basic tests for these two. More tests are needed
but will have to wait for state to be finished.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| | |
| |
| |
| |
| |
| | |
Start and Resize require further implementation work.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously tried to send resize events only after the exec
session successfully started, which makes sense (we might drop an
event or two that came in before the exec session started
otherwise). However, the start function blocks, so waiting
actually means we send no resize events at all, which is
obviously worse than losing a few.. Sending resizes before attach
starts seems to work fine in my testing, so let's do that until we
get bug reports that it doesn't work.
Fixes #5584
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
| |
This produces detailed information about the configuration of an
exec session in a format suitable for the new HTTP API.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
|
|
As part of the rework of exec sessions, we need to address them
independently of containers. In the new API, we need to be able
to fetch them by their ID, regardless of what container they are
associated with. Unfortunately, our existing exec sessions are
tied to individual containers; there's no way to tell what
container a session belongs to and retrieve it without getting
every exec session for every container.
This adds a pointer to the container an exec session is
associated with to the database. The sessions themselves are
still stored in the container.
Exec-related APIs have been restructured to work with the new
database representation. The originally monolithic API has been
split into a number of smaller calls to allow more fine-grained
control of lifecycle. Support for legacy exec sessions has been
retained, but in a deprecated fashion; we should remove this in
a few releases.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
