Should the "Stdin and TTY" item be checked off now that #12168 has been merged? Is the rest of the status up to date? I'm quite interested in using rkt over Docker and might be willing to do some work here.

@kamalmarhubi No jobs have been done for the Stdin & TTY yet, helps welcome :)
The image gc also should be easier than the others.
Enabling as many e2e tests as possible for rkt might be a little painful...

Besides, we are currently design/develop APIs for rkt, which should save us many effort maintaining all these in long term.

@yifan-gu when you say developing APIs, do you mean as a Go library, or something akin to the Docker daemon with, eg, an HTTP interface?

@kamalmarhubi No restful API at this time, we are going to use grpc. It should be easy to generate client bindings, and maybe we will do a more "docker client like" wrapper over the binding.

That makes sense. Does this mean there will be a new daemon to go along side the metadata service?

@kamalmarhubi Yes. but it's also optional, you don't require it to run rkt. It just provides easy access to the pod/image information.
That means it should run in non-root, and it's failover should not affect running pods.

@yifan-gu ah so it's not used for starting pods?

@kamalmarhubi No.

@kamalmarhubi FYI, here's the PR for the API interface rkt/rkt#1359

Awesome thanks!

Run e2e tests on local:

Ran 109 of 185 Specs in 7246.865 seconds
FAIL! -- 60 Passed | 49 Failed | 2 Pending | 74 Skipped --- FAIL: TestE2E (7246.87s)
FAIL

Not every failures are related to rkt. As I noticed I had bunch of failures running with docker locally as well.
Detailed logs are here:
https://gist.github.com/yifan-gu/da1d30bf077d99cfa71f

Trying to setup gce env for e2e tests next.

I've never run e2e in a non-gce environment, and I wouldn't be surprised if a lot of them fail. Yes, setting up a gce cluster would definitely help.

there a additional rather minor issues, I found related to rkt driver:

• cannot start new pod with "runonce"
• better error handling eg. "ppid file not found" message for not-defined but required volume scenario
• "container runtime" (describe node) always says "docker" regardless --container-runtime
• feature - rkt support for /cluster/* deployment scripts (we have that for libvirt)
• rkt with kvm engine support: kubelet logs/exec, gc

some of them are under our investigation

@yifan-gu: my question is, are you aware some of those ? are you working on some of them ? we can/will help you with some of them, but want to make sure, that we dont overlap

@ppalucki I am setting gce e2e test environments for rkt/k8s, so will get to these later, but feel free to take them, thanks :)

@yifan-gu : Can you tell, what's the current status of e2e tests with rkt, or is there any PR related with it ? I see only #7205

@woodbor Here is the brief result
FAIL! -- 65 Passed | 103 Failed | 0 Pending | 69 Skipped
Run last week
logs here: https://gist.github.com/yifan-gu/f970a0b3748543ee919f

FAIL! -- 109 Passed | 59 Failed | 0 Pending | 69 Skipped
Run yesterday with a hacked rkt that supports hostname /etc/hosts
logs here: https://gist.github.com/yifan-gu/51e29ef92428e4272d04

We are tracking more status in this google doc https://docs.google.com/document/d/1otDQ2LSubtBUaDfdM8ZcSdWkqRHup4Hqt1VX1jSxh6A/edit#

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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

Closing this since relevant issues should be handled in CRI or moved to the rktlet repository.