Godep: Add godep for rkt.

[yifan-gu]

rkt: v0.5.4
appc spec: v0.5.1

[yifan-gu]

@dchen1107 @vmarmol @bakins

[dchen1107]

LGTM on this Godep and will merge it once it is green.

[yifan-gu]

Thank you!

[pmorie]

Kicked shippable, looked like a flake.

[yifan-gu]

@pmorie Thank you!

[pmorie]

Yet another shippable flake, kicked again 👣

[vmarmol]

Travis is green, LGTM. Merging!

[erictune]

So, for docker, we vendor client libraries, but for rkt, we vendor the entire rkt implementation? And we plan to compile all of rkt into Kubelet?

Just thinking through what this means.

• Upgrading kubelet upgrades rkt support as well.
• how do we start kubelet in a container without a separate rkt binary? With --run_once?
• how is the rkt version reported, compared to how docker version is reported?

[vmarmol]

@erictune this (this PR's title) is a bit misleading, we still use the rkt binary for most operations. We are importing the client libraries and APIs around it. Today, it is a bit of an ugly hybrid. With time I think we will move fully to a client.

[pmorie]

@vmarmol, this threw me too and was why I was asking if we were embedding
rocket the other day.

On Thu, Apr 30, 2015 at 4:42 PM, Victor Marmol notifications@github.com
wrote:

@erictune https://github.com/erictune this is a bit misleading, we
still use the rkt binary for most operations. We are importing the client
libraries and APIs around it. Today, it is a bit of an ugly hybrid. With
time I think we will move fully to a client.

—
Reply to this email directly or view it on GitHub
#7410 (comment)
.

[erictune]

Is this just vendoring the client? That is a lot of files. Or is it
vendoring all of rkt? Is there a way to vendor just the client?

On Thu, Apr 30, 2015 at 1:44 PM, Paul Morie notifications@github.com
wrote:

@vmarmol, this threw me too and was why I was asking if we were embedding
rocket the other day.

On Thu, Apr 30, 2015 at 4:42 PM, Victor Marmol notifications@github.com
wrote:

@erictune https://github.com/erictune this is a bit misleading, we
still use the rkt binary for most operations. We are importing the client
libraries and APIs around it. Today, it is a bit of an ugly hybrid. With
time I think we will move fully to a client.

—
Reply to this email directly or view it on GitHub
<
#7410 (comment)

.

—
Reply to this email directly or view it on GitHub
#7410 (comment)
.

[yifan-gu]

@erictune That's because now we exposed the internal storage type of rkt to get the image manifest. I think we will fix it when rkt binary provides a way to retrieve the image manifest. All the rkt package should be removed. Only appc/spec is necessary.

[erictune]

Okay, as long as you have a plan :-)

On Fri, May 1, 2015 at 9:16 AM, Yifan Gu notifications@github.com wrote:

@erictune https://github.com/erictune That's because now we exposed the
internal storage type of rkt to get the image manifest. I think we will fix
it when rkt binary provides a way to retrieve the image manifest. All the
rkt package should be removed. Only appc/spec is necessary.

—
Reply to this email directly or view it on GitHub
#7410 (comment)
.