Well a couple of points, we are currently blocked from pushing docker-1.10 into fedora 23, because
On 03/28/2016 10:45 AM, Eric Paris wrote:
On Mon, 2016-03-28 at 09:27 -0400, Colin Walters wrote:
Hi,I personally see little value in the engineering effort required to
In some of my use cases I have OpenShift/Kubernetes clusters that are
primarily certified on 1.9, and so I'd like to keep using that. But
it'd be useful to be able to quickly try out 1.10 on some of my
nodes, or in cases outside of a Kube cluster.
Does anyone have any thoughts on this? What if we had two Docker
packages, and used a config option to determine which to run as
`docker.service` ?
install two versions at once. There just don't seem to me to be many
practical use cases. Actual users, people who need to get work done
with docker will not want to constantly flip back and forth. Docker
developers aren't like to want to do so as they are likely to just want
to work on the latest and greatest.
Which leaves me only able to think of the one oddball case you already
pointed out. Where kubernetes only claims support for 1.9 even though
Docker has released 1.10. Where a user may want to evaluate using plain
docker vs using kubernetes. In this situation you either have the case
where the user needs a feature in $KUBE_DOCKER_VERSION + 1, and they
both cannot use kube and cannot use $KUBE_DOCKER_VERSION or they do not
need a docker feature in $VERSION+1 in which case they should be able
to do the comparison with only 1 version installed.
So I don't see a real reason to need 2 versions installed from a user
story point of view. And the fact that there is only one version of
docker supported in a fedora release at a time leads bolsters my
feelings like this is not something a user would need/want. In which
case it makes me ask 'obviously I'm missing the point, why is someone
asking for this?'
I can only assume it is because of the pain involved in changing the
version of a package when using rpmostree as a developer. Which makes
me ask, 'should we be using atomic in this case?' When the explicit use
case is about quickly iterating between two versions of packages and
rpmostree is about entire images, it just seems like we have an
impeedance mismatch which maybe shouldn't be 'solved'...
-Eric
it will break k8s, and it looks like we could have the same problem when we go to ship docker-1.10
into rhel in May.
If we shipped both in the same package a user with k8s could easily switch to that version
and we could allow people in Fedora to use the latest version.
On atomic host, we have been told that the two use cases of using it for latest docker versus using it with
k8s and OpenShift need to be supported. Which is why we want to ship one version to support both.
It would be nice if docker would slow down enough for k8s to stay up, but docker is already in rc2 for docker-1.11.