Attach: Tracking issue

[euank]

Attach is one of the larger unknowns in this integration. The work that needs to be done here is dependent on rkt providing such a feature, and significant work remains Kubernetes side for the final "CRI" integration to happen.

It's a complete unknown on the rkt side, and an "known-ish" on the Kubernetes side currently.

Relevant issues:
rkt/rkt#1799
kubernetes/kubernetes#29579

We should split out an additional implementation issue or turn this into one once the above two issues are resolved.

Based on the current lay of things, I think the work will split up roughly as the following:

• rkt: Implement the needed features for attach to function at all
• CRI: Commit to "option 3" from their issue, effectively implementing attach via an exec'd container
• CRI: Provide an interface for "create an attach-helper container and give me back a url"
• CRI-runtimes-shared-code: Create a library which all runtimes can share that creates the expected api/endpoint/auth for api-service to connect to, and requires a small number of stub methods to be implemented (namely 'attach', 'exec')
• rktlet: Provide the implementation for those stubs using rkt
• rktlet: Package and ship the above implementation as a container
• rktlet: Implement the CRI method by translating it into running our specific helper container

[lucab]

Regarding the first point (rkt implementation), a tentative plan come up from the discussion at rkt/rkt#1799 (comment). Low-level implementation of a per-container ttymux service in progress.

[lucab]

I have a working ttymux POC but it looks like kubernetes requirements are more complex than that and also require separate stdin/stdout/stderr handling, see rkt/rkt#1799 (comment). For rkt, this means that systemd needs to support exposing each single stream instead of tty content. I just submitted systemd/systemd#4179 to systemd for that and if accepted I can proceed with wiring in support for it.

[alban]

rkt has now an "attach" command, enabled with RKT_EXPERIMENT_ATTACH=true
https://github.com/rkt/rkt/blob/master/Documentation/subcommands/attach.md

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.