[jira] [Commented] (MESOS-1886) Allow docker pull on each run to be configurable
[
https://issues.apache.org/jira/browse/MESOS-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492609#comment-14492609
]
Adam Avilla commented on MESOS-1886:
+1 to [~codecraig]'s comment.
Also, I am having a hard time figuring out how this is configured when creating
a mesos task. Is it a top level attribute in the "container" hash? E.g.
{code}
"container": {
"force": true,
...
}
{code}
?
> Allow docker pull on each run to be configurable
>
>
> Key: MESOS-1886
> URL: https://issues.apache.org/jira/browse/MESOS-1886
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 0.20.1
>Reporter: Chris Heller
>Assignee: Timothy Chen
>Priority: Minor
> Labels: docker
>
> With 0.20.1 the behavior of a docker container has changed (see MESOS-1762).
> This change brings the docker behavior more in line with that of {{docker
> run}}.
> I propose,if the image given explicitly has the ":latest" tag, this should
> signify to mesos that an unconditional `docker pull` should be done on the
> image... and if it should fail for any reason (i.e. the registry is
> unavailable) we fall back to the current behavior.
> This would break slightly with the semantics of how the docker command line
> operates, but the alternative is to require explicit tags on every release --
> which is a hinderance when developing a new image, or one must log in to each
> node and run an explicit `docker pull`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2588) Create pre-create hook before a Docker container launches
[ https://issues.apache.org/jira/browse/MESOS-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538339#comment-14538339 ] Adam Avilla commented on MESOS-2588: +1. I think this would be an excellent feature. Let me know how I can help get this going and expose through Marathon / Chronos. > Create pre-create hook before a Docker container launches > - > > Key: MESOS-2588 > URL: https://issues.apache.org/jira/browse/MESOS-2588 > Project: Mesos > Issue Type: Bug > Components: docker >Reporter: Timothy Chen >Assignee: haosdent > > To be able to support custom actions to be called before launching a docker > contianer, we should create a hook that can be extensible and allow > module/hooks to be performed before a docker container is launched. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3599) COMMAND health checks with marathon running in slave context broken
[
https://issues.apache.org/jira/browse/MESOS-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976649#comment-14976649
]
Adam Avilla commented on MESOS-3599:
[~ekesken] in your python example above you are having to do the loop
inspection to figure out where you need to docker logs / exec. Do you know if
anyone on mesos team is looking at exposing this just as an ENV var so that you
could potentially change to something like:
{code}
docker logs $DOCKER_PROCESS_NAME | grep 'Welcome to interaction-indexer.'
{code}
> COMMAND health checks with marathon running in slave context broken
> ---
>
> Key: MESOS-3599
> URL: https://issues.apache.org/jira/browse/MESOS-3599
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Erhan Kesken
>Assignee: haosdent
>Priority: Critical
>
> When deploying Mesos 0.23rc4 with latest Marathon 0.10.0 RC3 command health
> check stop working. Rolling back to Mesos 0.22.1 fixes the problem.
> Containerizer is Docker.
> All packages are from official Mesosphere Ubuntu 14.04 sources.
> The issue must be analyzed further.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3688) Get Container Name information when launching a container task
[
https://issues.apache.org/jira/browse/MESOS-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1497#comment-1497
]
Adam Avilla commented on MESOS-3688:
+1. I could really use the feature to have the container name or id available
as an environment variable so that I could do things around health checking
like:
{code}
docker exec $MESOS_CONTAINER_NAME cat smoke.tests | smoke_test_runner
$HOST:$PORT
{code}
Thanks!
> Get Container Name information when launching a container task
> --
>
> Key: MESOS-3688
> URL: https://issues.apache.org/jira/browse/MESOS-3688
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 0.24.1
>Reporter: Raffaele Di Fazio
> Labels: mesosphere
>
> We want to get the Docker Name (or Docker ID, or both) when launching a
> container task with mesos. The container name is generated by mesos itself
> (i.e. mesos-77e5fde6-83e7-4618-a2dd-d5b10f2b4d25, obtained with "docker ps")
> and it would be nice to expose this information to frameworks so that this
> information can be used, for example by Marathon to give this information to
> users via a REST API.
> To go a bit in depth with our use case, we have files created by fluentd
> logdriver that are named with Docker Name or Docker ID (full or short) and we
> need a mapping for the users of the REST API and thus the first step is to
> make this information available from mesos.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3688) Get Container Name information when launching a container task
[
https://issues.apache.org/jira/browse/MESOS-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977263#comment-14977263
]
Adam Avilla commented on MESOS-3688:
I didn't realize there are two different containerizers :/. Maybe just:
{code}
MesosContainerId
{code}
and
{code}
DockerContainerId
{code}
?
Also, will these be available in or outside the container?
> Get Container Name information when launching a container task
> --
>
> Key: MESOS-3688
> URL: https://issues.apache.org/jira/browse/MESOS-3688
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Affects Versions: 0.24.1
>Reporter: Raffaele Di Fazio
>Assignee: Kapil Arya
> Labels: mesosphere
>
> We want to get the Docker Name (or Docker ID, or both) when launching a
> container task with mesos. The container name is generated by mesos itself
> (i.e. mesos-77e5fde6-83e7-4618-a2dd-d5b10f2b4d25, obtained with "docker ps")
> and it would be nice to expose this information to frameworks so that this
> information can be used, for example by Marathon to give this information to
> users via a REST API.
> To go a bit in depth with our use case, we have files created by fluentd
> logdriver that are named with Docker Name or Docker ID (full or short) and we
> need a mapping for the users of the REST API and thus the first step is to
> make this information available from mesos.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3765) Make offer size adjustable (granularity)
[
https://issues.apache.org/jira/browse/MESOS-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992716#comment-14992716
]
Adam Avilla commented on MESOS-3765:
+1
I know we have talked about wanting this feature namely in the context of
agents need to run other things and can't be fully consumed by mesos tasks only.
> Make offer size adjustable (granularity)
>
>
> Key: MESOS-3765
> URL: https://issues.apache.org/jira/browse/MESOS-3765
> Project: Mesos
> Issue Type: Improvement
> Components: allocation
>Reporter: Alexander Rukletsov
>
> The built-in allocator performs "coarse-grained" allocation, meaning that it
> always allocates the entire remaining agent resources to a single framework.
> This may heavily impact allocation fairness in some cases, for example in
> presence of numerous greedy frameworks and a small number of powerful agents.
> A possible solution would be to allow operators explicitly specify
> granularity via allocator flags. While this can be tricky for non-standard
> resources, it's pretty straightforward for {{cpus}} and {{mem}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
