It is not for the Debian image which is what we use by default. There was talk of moving to the Container VMs image (which does have it), but that front hasn't moved in some time.

@filbranden

On Thu, Oct 2, 2014 at 12:57 PM, Victor Marmol notifications@github.com
wrote:

It is not for the Debian image which is what we use by default. There was
talk of moving to the Container VMs image (which does have it), but that
front hasn't moved in some time.

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

So... Is the plan to use containervm?

Is it feasible? If we throw salt on top of it, will it reconfigure docker
flags and everything else the way we need?
On Oct 2, 2014 6:36 PM, "Filipe Brandenburger" notifications@github.com
wrote:

So... Is the plan to use containervm?

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

I don't know, I think it makes a few of assumptions on containervm (e.g. that it's Debian and not a tiny distro such as tinycore; that you can run Salt on it; that you can even SSH to its base OS) that I'm not sure we want to commit to... Furthermore, it's one more thing to watch for that we might break every time we release a new one.

@jkaplowitz Would it be acceptable to just enable memory container by default on the Debian image instead? Or maybe making it possible to enable it through a startup script in metadata?

Another possibility is to use another distro. For instance, Vagrant uses Fedora 20 and I believe memcg is enabled there... Why are we using different distros in these two different environments?

By Tue time we move away from Debian as containervm, I think we will have
obviated Salt.
On Oct 2, 2014 7:16 PM, "Filipe Brandenburger" notifications@github.com
wrote:

I don't know, I think it makes a few of assumptions on containervm (e.g.
that it's Debian and not a tiny distro such as tinycore; that you can run
Salt on it; that you can even SSH to its base OS) that I'm not sure we want
to commit to... Furthermore, it's one more thing to watch for that we might
break every time we release a new one.

@jkaplowitz https://github.com/jkaplowitz Would it be acceptable to
just enable memory container by default on the Debian image instead? Or
maybe making it possible to enable it through a startup script in metadata?

Another possibility is to use another distro. For instance, Vagrant uses
Fedora 20 and I believe memcg is enabled there... Why are we using
different distros in these two different environments?

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

Yeah, I think it should work.

Brendan
On Oct 2, 2014 6:49 PM, "Tim Hockin" notifications@github.com wrote:

Is it feasible? If we throw salt on top of it, will it reconfigure docker
flags and everything else the way we need?
On Oct 2, 2014 6:36 PM, "Filipe Brandenburger" notifications@github.com
wrote:

So... Is the plan to use containervm?

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

.

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

I'd rather not move to Fedora either. Systemd support on our stack is not
as good as we'd like it to be just yet.
On Oct 2, 2014 7:40 PM, "Brendan Burns" notifications@github.com wrote:

Yeah, I think it should work.

Brendan
On Oct 2, 2014 6:49 PM, "Tim Hockin" notifications@github.com wrote:

Is it feasible? If we throw salt on top of it, will it reconfigure
docker
flags and everything else the way we need?
On Oct 2, 2014 6:36 PM, "Filipe Brandenburger" notifications@github.com

wrote:

So... Is the plan to use containervm?

Reply to this email directly or view it on GitHub
<

#1548 (comment)

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/1548#issuecomment-57739282>

.

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

#738 was filed a while ago to use the latest containervm image by default if cloud provider is gce.

Salt should be able to take the container VM and update it. We can use it to update the kublet that is there also.