You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Adam B (JIRA)" <ji...@apache.org> on 2015/01/06 09:23:34 UTC

[jira] [Commented] (MESOS-2197) Allow frameworks using Docker containerizer to prioritize resourceOffers with precached Docker images

    [ 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)