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