On Mon, 2016-03-28 at 09:27 -0400, Colin Walters wrote:
Hi,
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` ?
I personally see little value in the engineering effort required to
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