[
https://issues.apache.org/jira/browse/MESOS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14265850#comment-14265850
]
Timothy Chen commented on MESOS-2197:
-------------------------------------
It's tricky since as soon a image is executed in any slave, that image is by
default cached on the slave.
That means the attributes that is declared becomes dynamic, if we want to
convey the more accurate information.
A compromise is to just serve a static list of docker images, which then it's
almost the same as just listing slave attributes and I don't see a need of a
hook.
And as Adam pointed out, even if the images are up to date we still need to
pass it down. I think this is going to be a common problem though as we move to
a more omega like scheduler we will need to be passing a lot more state to each
scheduler to make local decisions. I don't see any other alternative then
really just giving them all the state it needs.
Probably an optimization is to only push images information once, and other
offers will only send down diffs which is when images are become cached or
uncached on the slave.
> 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)
