[
https://issues.apache.org/jira/browse/MESOS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14265837#comment-14265837
]
Adam B commented on MESOS-2197:
-------------------------------
I see your point. The easiest solution I can come up with is that the docker
containerizer could update the slave's attributes to contain a list of
precached docker image names/tags. Then this information would be forwarded
onto the framework in each resource offer. The only question is whether we
really want to put a long list of docker images into every resource offer
(could get big).
Maybe this would fit in well as an optional hook into the containerizer.
Any thoughts on this from [~tnachen] or [~karya]?
> Allow frameworks using Docker containerizer to prioritize resourceOffers with
> precached Docker images
> -----------------------------------------------------------------------------------------------------
>
> Key: MESOS-2197
> URL: https://issues.apache.org/jira/browse/MESOS-2197
> Project: Mesos
> Issue Type: Improvement
> Reporter: Lans Carstensen
> Labels: mesosphere
>
> Docker container / task startup latency is significantly different on slaves
> that have already retrieved Docker images vs. those that haven't. It would
> be desirable to give a framework the ability to sort/prioritize offers based
> on whether or not the Docker image is already present or not.
> Ideally this sort of signalling could also be leveraged to allow mesos slaves
> to pre-populate Docker images that frameworks are requesting.
> Keeping in mind that image tags are mutable. Just because there is an
> "ubuntu:latest" image present on a slave doesn't mean that's the image that
> will be used (i.e. force_pull_image=true -
> https://reviews.apache.org/r/28190/ ). This is especially true of continuous
> integration / deployment environments where "latest" could be changing
> frequently. The framework may end up having to resolve an image tag to an
> image id first and use that for comparison with the slaves.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
