Skipping latest Docker 1.11 release?

[Kevin Heatwole]

Is CoreOS skipping the latest Docker 1.11 release?

[Alex Polvi]

Kevin, we are committed to shipping docker releases. 1.11 introduced some major changes and another round of difficultly to handle an update. We are working through the best way to get it released.

-Alex

On Mon, Jun 6, 2016 at 6:49 AM, Kevin Heatwole <ktwa...@gmail.com> wrote:

Is CoreOS skipping the latest Docker 1.11 release?

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yann degat]

hi

any news on this update ?

there's a lot of issues fixed with 1.11 ( and surely lot of new ones ), but isn't it the philposophy of the alpha channel ?

[Alex Crawford]

On 06/21, yann degat wrote:
> any news on this update ?

We are working toward getting Docker 1.11.2 into the next Alpha release
(tracking issue [1]). We were hoping to have an implementation of Docker
in rkt working well enough to ship, but there have been a few bumps
along the way. Docker in rkt would decouple Docker updates from OS
updates, allowing users to choose a particular version of Docker that
works best for them. While we continue to work on this, we're going to
ship a newer version of Docker. Stay tuned!

-Alex

[1]: https://github.com/coreos/bugs/issues/1414

[DEGAT Yann]

great news !

( i've also tried to run docker in rkt... all by myself... abandonned )

bitmessage address: BM-2cTD49oR1Xwu28XswZoh4qRMeeQwpUYvhY

[Alex Crawford]

On 06/21, DEGAT Yann wrote:
> great news !
>
> ( i've also tried to run docker in rkt... all by myself... abandonned )

If you are interested, we have some POC scripts [1] posted which do run
Docker within rkt nicely.

-Alex

[1]: https://groups.google.com/d/msg/coreos-dev/icuel9OveRQ/0UIiE43yAwAJ

[Cameron Davison]

Is decoupling Docker updates from the OS a good thing? I guess I was thinking that CoreOS is an OS to run docker images and then some Unix tools to help debug/log things running in docker. If we had to start updating docker out of band of the normal CoreOS updates would CoreOS auto do that as well, or would that be manual intervention? Is there an issue for the docker decoupling? Where does that decoupling stop? Would y'all want to eventually decouple rkt as well and fleet and etcd?

Thanks,
Cameron

[Kevin Heatwole]

On Wednesday, June 22, 2016 at 8:37:06 AM UTC-4, Cameron Davison wrote:

Is decoupling Docker updates from the OS a good thing?

In Docker 1.12, they allow Docker daemon to be restarted on update without taking down the containers that the Docker daemon manages (I think). How would this work if the daemon runs in a container? Would the containerd processes that the daemon spawns run outside the daemon container?

[Alex Crawford]

On 06/22, Cameron Davison wrote:
> Is decoupling Docker updates from the OS a good thing? I guess I was
> thinking that CoreOS is an OS to run docker images and then some Unix tools
> to help debug/log things running in docker. If we had to start updating
> docker out of band of the normal CoreOS updates would CoreOS auto do that
> as well, or would that be manual intervention?

The idea would be for CoreOS to specify a default Docker version. As the
OS updated itself from one version to the next, Docker would continue to
follow the recommended version for that release of the OS. Out of the
box, Docker would update itself over time.

This still allows the user to pin Docker to a particular version or skip
ahead of what the OS currently recommends.

> Is there an issue for the docker decoupling? Where does that
> decoupling stop? Would y'all want to eventually decouple rkt as well
> and fleet and etcd?

In fact, we would! There is a design doc [1] with a bit more detail.

-Alex

[1]: https://docs.google.com/document/d/1W0vqVctpxpALhOyyZAHaYEPKukGSQOf_L_B3Qx_NR9w/edit

[Alex Crawford]

On 06/22, Kevin Heatwole wrote:
> In Docker 1.12, they allow Docker daemon to be restarted on update without
> taking down the containers that the Docker daemon manages (I think). How
> would this work if the daemon runs in a container? Would the containerd
> processes that the daemon spawns run outside the daemon container?

rkt has the ability to use different implementations of the stage-1. The
default implementation uses traditional containers, but we would use an
alternate implementation that just chroots the process. This lower level
of containment should allow Docker to continue to manage it's containers
the way it wants.

-Alex