Re: CentOS/EL7 packages

[Maxime Brugidou]

CO6 kernel with EPEL has docker support. Docker 1.1.2 is available and 1.2
is in testing.

Although it would be nice to have a mesos RPM for CO7 too of course.
On Aug 27, 2014 11:32 PM, "Hoffman, Steve"  wrote:

>  I loved hearing that 1st class docker support has come to mesos in the
> 0.20 release at last week’s mesoscon.
> However, docker support requires a docker capable OS — and since we are a
> CentOS shop leaves me with 2 options:
>
>1. hack up a CO6 image to bleeding edge kernel etc (and get the system
>guys to support it) and use the 0.20 packages from mesosphere (we’re going
>from CO6.4 -> CO7.0 next) OR
>2. find a CO7 package — which doesn’t seem to exist
>
> When I asked mesosphere about option 2 they told me it is on their roadmap
> — which doesn’t really help as it could be tomorrow or in a year for all I
> know…
> They did reference some open source work based on FPM here:
> https://github.com/mesosphere/mesos-deb-packaging they use with fedora,
> etc.
>
>  Anybody working on this already or want to work with me to make this
> happen?
>
>  Steve
>

Re: CentOS/EL7 packages

[Cosmin Lehene]

I'm working on getting this Puppet module to work on CentOS 7 
https://github.com/deric/puppet-mesos using the Mesosphere CentOS 6 rpm.

I'll probably change it later to install from source and not rely on rpms.

This said, I think a Docker container for Mesos would be way better.

Cosmin

From: , Steve 
mailto:steve.hoff...@orbitz.com>>
Reply-To: "user@mesos.apache.org" 
mailto:user@mesos.apache.org>>
Date: Wednesday, August 27, 2014 at 3:32 PM
To: "user@mesos.apache.org" 
mailto:user@mesos.apache.org>>
Subject: CentOS/EL7 packages

I loved hearing that 1st class docker support has come to mesos in the 0.20 
release at last week's mesoscon.
However, docker support requires a docker capable OS - and since we are a 
CentOS shop leaves me with 2 options:

  1.  hack up a CO6 image to bleeding edge kernel etc (and get the system guys 
to support it) and use the 0.20 packages from mesosphere (we're going from 
CO6.4 -> CO7.0 next) OR
  2.  find a CO7 package - which doesn't seem to exist

When I asked mesosphere about option 2 they told me it is on their roadmap - 
which doesn't really help as it could be tomorrow or in a year for all I know...
They did reference some open source work based on FPM here: 
https://github.com/mesosphere/mesos-deb-packaging they use with fedora, etc.

Anybody working on this already or want to work with me to make this happen?

Steve

Re: Design Review: Maintenance Primitives

[Sharma Podila]

Nicely written doc. Here's a few thoughts:

- There's some commonality between the existing offerRescinded() and the
new inverseOffer(). Maybe consider having same method names for them with
differing signatures? I'd second Maxime's point about possibly renaming
inverseOffer to something else - maybe offerRescind() or offerRevoke()?

- Offer has hostname but InverseOffer doesn't, is that intentional?

- I like it that the operations of maintenance Vs. draining are separated
out. Draining deactivates the slave, and should also immediately rescind
all outstanding offers (I suppose using the offers would result in
TASK_LOST, but it would play nice with frameworks if offers are rescinded
proactively).

- For maintenance across all or a large part of the cluster, these
maintenance primitives would be helpful. Another piece required to
achieving fully automated maintenance (say, upgrade kernel patch on all
slaves) would be to have a maintenance orchestration engine that has
constraints such as "ensure not more than X% of slave type A are down for
maintenance concurrently". That is, automated rolling upgrades with SLA on
uptime/availability. Such an engine could accomplish its task using these
primitives.






On Tue, Aug 26, 2014 at 2:23 PM, Maxime Brugidou 
wrote:

> Glad to see that you are really thinking this through.
>
> Yes it's explicit that resources won't be revoked and will stay
> outstanding in this case but I would just add that the slave won't enter
> the "drained" state. It's just hard to follow the
> drain/revoke/outstanding/inverse offer/reclaim vocabulary. Actually, did
> you also think about the name? Inverse offer sounds weird to me. Maybe
> resourceOffers()  and resource Revoke()? You probably have better arguments
> and idea than me though :)
>
> Another small note: the OfferID in the inverse offer is completely new and
> just used to identify the inverse offer right? I got a bit confused about a
> link between a previous offerID and this but then I saw the Resource field.
> Wouldn't it be clearer to have InverseOfferID?
>
> Thanks for the work! I really want to have these primitives.
> On Aug 26, 2014 10:59 PM, "Benjamin Mahler" 
> wrote:
>
>> You're right, we don't account for that in the current design because
>> such a framework would be relying on disk resources outside of the sandbox.
>> Currently, we don't have a model for these "persistent" resources (e.g.
>> disk volume used for HDFS DataNode data). Unlike the existing resources,
>> persistent resources will not be tied to the lifecycle of the executor/task.
>>
>> When we have a model for persistent resources, I can see this fitting
>> into the primitives we are proposing here. Since inverse offers work at the
>> resource level, we can provide control to the operators to determine
>> whether the persistent resources should be reclaimed from the framework as
>> part of the maintenance:
>>
>> E.g. If decommissioning a machine, the operator can ensure that all
>> persistent resources are reclaimed. If rebooting a machine, the operator
>> can leave these resources allocated to the framework for when the machine
>> is back in the cluster.
>>
>> Now, since we have the soft deadlines on inverse offers, a framework like
>> HDFS can determine when it can comply to inverse offers based on the global
>> data replication state (e.g. always ensure that 2/3 replicas of a block are
>> available). If relinquishing a particular data volume would mean that only
>> 1 copy of a block is available, the framework can wait to comply with the
>> inverse offer, or can take steps to create more replicas.
>>
>> One interesting question is how the resource expiry time will interact
>> with persistent resources, we may want to expose the expiry time at the
>> resource level rather than the offer level. Will think about this.
>>
>> *However could you specify that when you drain a slave with hard:false
>>> you don't enter the drained state even when the deadline has passed if
>>> tasks are still running? This is not explicit in the document and we want
>>> to make sure operators have the information about this and could avoid
>>> unfortunate rolling restarts.*
>>
>>
>> This is explicit in the document under the soft deadline section: the
>> inverse offer will remain outstanding after the soft deadline elapses, we
>> won't forcibly drain the task. Anything that's not clear here?
>>
>>
>>
>>
>> On Mon, Aug 25, 2014 at 1:08 PM, Maxime Brugidou <
>> maxime.brugi...@gmail.com> wrote:
>>
>>> Nice work!
>>>
>>> First question: don't you think that operations should differentiate
>>> short and long maintenance?
>>> I am thinking about frameworks that use persistent storage on disk for
>>> example. A short maintenance such as a slave reboot or upgrade could be
>>> done without moving the data to another slave. However decommissioning
>>> requires to drain the storage too.
>>>
>>> If you have an HDFS datanode with 50TB of (replicated) data, you might
>>> not want to drain

Re: Mesos autoscaling script

[Ankur Chauhan]

Looks cool! I'll check it out. 

Sent from my iPhone

> On Aug 27, 2014, at 2:00 PM, Michael Babineau  
> wrote:
> 
> I wrote a script to automatically launch/terminate Mesos slaves on EC2 based 
> on available resources:
> https://github.com/thefactory/autoscale-python/blob/master/examples/mesos_ec2.py
> 
> Scaling actions are performed by a provider-specific component, so supporting 
> Google Compute Engine or another provider is simply a matter of implementing 
> the same (trivial) interface. Same goes for incorporating other data sources 
> or custom scaling logic: just write a drop-in replacement for an existing 
> component.
> 
> I've started a Python library around this pattern. Current support 
> is...humble.. (only "Mesos based on disk/mem/cpu free on EC2"), but I'd love 
> to build out a suite of components to handle different use cases (non-Mesos; 
> non-EC2; alternative logic; etc). Please check it out:
> https://github.com/thefactory/autoscale-python
> 
> Thanks to Connor Doyle for the early design feedback. If anybody else has 
> thoughts on how to improve it, I'd love to hear them!

CentOS/EL7 packages

[Hoffman, Steve]

I loved hearing that 1st class docker support has come to mesos in the 0.20 
release at last week's mesoscon.
However, docker support requires a docker capable OS - and since we are a 
CentOS shop leaves me with 2 options:

  1.  hack up a CO6 image to bleeding edge kernel etc (and get the system guys 
to support it) and use the 0.20 packages from mesosphere (we're going from 
CO6.4 -> CO7.0 next) OR
  2.  find a CO7 package - which doesn't seem to exist

When I asked mesosphere about option 2 they told me it is on their roadmap - 
which doesn't really help as it could be tomorrow or in a year for all I know...
They did reference some open source work based on FPM here: 
https://github.com/mesosphere/mesos-deb-packaging they use with fedora, etc.

Anybody working on this already or want to work with me to make this happen?

Steve

Re: Mesos-slave 0.20.0 fails to register in mesos-master if containerizers=docker,mesos, works with containerizers=mesos

[Jie Yu]

I0827 22:58:18.789118  3383 docker.cpp:649] Recovering Docker containers

Seems that the slave stuck at recovering docker containers.

- Jie


On Wed, Aug 27, 2014 at 2:00 PM, Javier Ruiz Jiménez 
wrote:

> Hi all,
>
> My first post in the user list. Writing from Spain.
>
> I am setting up a Mesos Cluster and after upgrading to 0.20.0 and re
> configuring to use native docker functionality (remove Deimos) I am not
> able to containerizers=docker
>
> Releases:
> - Mesos-slave: Version: 0.20.0 Build: 2014-08-22 05:05:59 from repository
> http://repos.mesosphere.io/
> - Mesos-master: Version: 0.20.0 Build: 2014-08-22 05:05:59  from
> repository http://repos.mesosphere.io/
> - O.S.:  Ubuntu 14.04.1 LTS
> - Marathon: Marathon 0.7.0-SNAPSHOT
> - Docker version 1.2.0, build fa7b24f
>
> Installation:
> - Single host running mesos-master, mesos-slave, zookeeper and marathon
>
> If I run mesos-slave with --containerizers=docker,mesos , the mesos UI
> doesn't show any slaves or resources. No detection of master.
>
> If I run mesos-slave with --containerizers=mesos , the mesos UI shows the
> slaves and the resources.
>
> Where can I look for more information?
>
> I plan to build from repository to see if with the latest code it works.
>
> I don't see any relevant info in the log:
>
> Log for --containerizers=docker,mesos:
> Command: mesos-slave --master=192.168.0.57:5050
> --containerizers=mesos,docker  --hostname=192.168.0.57 --IP=192.168.0.57
> --log_dir=/var/log/mesos
> 
> I0827 22:58:17.774178  3379 logging.cpp:142] INFO level logging started!
> I0827 22:58:17.775691  3379 main.cpp:126] Build: 2014-08-22 05:05:59 by
> root
> I0827 22:58:17.775956  3379 main.cpp:128] Version: 0.20.0
> I0827 22:58:17.776199  3379 main.cpp:131] Git tag: 0.20.0
> I0827 22:58:17.776407  3379 main.cpp:135] Git SHA:
> f421ffdf8d32a8834b3a6ee483b5b59f65956497
> I0827 22:58:17.776654  3379 containerizer.cpp:89] Using isolation:
> posix/cpu,posix/mem
> I0827 22:58:18.783756  3379 main.cpp:149] Starting Mesos slave
> I0827 22:58:18.784618  3387 slave.cpp:167] Slave started on 1)@
> 192.168.0.57:5051
> I0827 22:58:18.784915  3387 slave.cpp:278] Slave resources: cpus(*):2;
> mem(*):15025; disk(*):26760; ports(*):[31000-32000]
> I0827 22:58:18.785161  3387 slave.cpp:306] Slave hostname: 192.168.0.57
> I0827 22:58:18.785348  3387 slave.cpp:307] Slave checkpoint: true
> I0827 22:58:18.787921  3381 state.cpp:33] Recovering state from
> '/tmp/mesos/meta'
> I0827 22:58:18.788781  3381 status_update_manager.cpp:193] Recovering
> status update manager
> I0827 22:58:18.789072  3381 containerizer.cpp:252] Recovering containerizer
> I0827 22:58:18.789118  3383 docker.cpp:649] Recovering Docker containers
>
> Log for --containerizers=mesos:
> Command: mesos-slave --master=192.168.0.57:5050 --containerizers=mesos
>  --hostname=192.168.0.57 --IP=192.168.0.57 --log_dir=/var/log/mesos
> __
> I0827 22:53:09.960764  3369 logging.cpp:142] INFO level logging started!
> I0827 22:53:09.962329  3369 main.cpp:126] Build: 2014-08-22 05:05:59 by
> root
> I0827 22:53:09.962749  3369 main.cpp:128] Version: 0.20.0
> I0827 22:53:09.963065  3369 main.cpp:131] Git tag: 0.20.0
> I0827 22:53:09.963369  3369 main.cpp:135] Git SHA:
> f421ffdf8d32a8834b3a6ee483b5b59f65956497
> I0827 22:53:09.963709  3369 containerizer.cpp:89] Using isolation:
> posix/cpu,posix/mem
> I0827 22:53:09.968011  3369 main.cpp:149] Starting Mesos slave
> I0827 22:53:09.968703  3377 slave.cpp:167] Slave started on 1)@
> 192.168.0.57:5051
> I0827 22:53:09.969319  3377 slave.cpp:278] Slave resources: cpus(*):2;
> mem(*):15025; disk(*):26760; ports(*):[31000-32000]
> I0827 22:53:09.969703  3377 slave.cpp:306] Slave hostname: 192.168.0.57
> I0827 22:53:09.969912  3377 slave.cpp:307] Slave checkpoint: true
> I0827 22:53:09.972486  3377 state.cpp:33] Recovering state from
> '/tmp/mesos/meta'
> I0827 22:53:09.972882  3377 state.cpp:62] Failed to find the latest slave
> from '/tmp/mesos/meta'
> I0827 22:53:09.973140  3377 status_update_manager.cpp:193] Recovering
> status update manager
> I0827 22:53:09.973368  3377 containerizer.cpp:252] Recovering containerizer
> I0827 22:53:09.973819  3377 slave.cpp:3195] Finished recovery
> I0827 22:53:09.974473  3377 slave.cpp:589] New master detected at
> master@192.168.0.57:5050
> I0827 22:53:09.974822  3370 status_update_manager.cpp:167] New master
> detected at master@192.168.0.57:5050
> I0827 22:53:09.974983  3377 slave.cpp:625] No credentials provided.
> Attempting to register without authentication
> I0827 22:53:09.975147  3377 slave.cpp:636] Detecting new master
> I0827 22:53:10.758889  3374 slave.cpp:754] Registered with master
> master@192.168.0.57:5050; given slave ID
> 20140827-224307-956344512-5050-3182-0
> I0827 22:53:10.759145  3374 slave.cpp:767] Checkpointing SlaveInfo to
> '/tmp/mesos/meta/slaves/20140827-224307-956344512-5050-3182-0/slave.info'
>
> Thanks.
> --
> Javier
>

Mesos-slave 0.20.0 fails to register in mesos-master if containerizers=docker,mesos, works with containerizers=mesos

[Javier Ruiz Jiménez]

Hi all,

My first post in the user list. Writing from Spain.

I am setting up a Mesos Cluster and after upgrading to 0.20.0 and re
configuring to use native docker functionality (remove Deimos) I am not
able to containerizers=docker

Releases:
- Mesos-slave: Version: 0.20.0 Build: 2014-08-22 05:05:59 from repository
http://repos.mesosphere.io/
- Mesos-master: Version: 0.20.0 Build: 2014-08-22 05:05:59  from repository
http://repos.mesosphere.io/
- O.S.:  Ubuntu 14.04.1 LTS
- Marathon: Marathon 0.7.0-SNAPSHOT
- Docker version 1.2.0, build fa7b24f

Installation:
- Single host running mesos-master, mesos-slave, zookeeper and marathon

If I run mesos-slave with --containerizers=docker,mesos , the mesos UI
doesn't show any slaves or resources. No detection of master.

If I run mesos-slave with --containerizers=mesos , the mesos UI shows the
slaves and the resources.

Where can I look for more information?

I plan to build from repository to see if with the latest code it works.

I don't see any relevant info in the log:

Log for --containerizers=docker,mesos:
Command: mesos-slave --master=192.168.0.57:5050
--containerizers=mesos,docker  --hostname=192.168.0.57 --IP=192.168.0.57
--log_dir=/var/log/mesos

I0827 22:58:17.774178  3379 logging.cpp:142] INFO level logging started!
I0827 22:58:17.775691  3379 main.cpp:126] Build: 2014-08-22 05:05:59 by root
I0827 22:58:17.775956  3379 main.cpp:128] Version: 0.20.0
I0827 22:58:17.776199  3379 main.cpp:131] Git tag: 0.20.0
I0827 22:58:17.776407  3379 main.cpp:135] Git SHA:
f421ffdf8d32a8834b3a6ee483b5b59f65956497
I0827 22:58:17.776654  3379 containerizer.cpp:89] Using isolation:
posix/cpu,posix/mem
I0827 22:58:18.783756  3379 main.cpp:149] Starting Mesos slave
I0827 22:58:18.784618  3387 slave.cpp:167] Slave started on 1)@
192.168.0.57:5051
I0827 22:58:18.784915  3387 slave.cpp:278] Slave resources: cpus(*):2;
mem(*):15025; disk(*):26760; ports(*):[31000-32000]
I0827 22:58:18.785161  3387 slave.cpp:306] Slave hostname: 192.168.0.57
I0827 22:58:18.785348  3387 slave.cpp:307] Slave checkpoint: true
I0827 22:58:18.787921  3381 state.cpp:33] Recovering state from
'/tmp/mesos/meta'
I0827 22:58:18.788781  3381 status_update_manager.cpp:193] Recovering
status update manager
I0827 22:58:18.789072  3381 containerizer.cpp:252] Recovering containerizer
I0827 22:58:18.789118  3383 docker.cpp:649] Recovering Docker containers

Log for --containerizers=mesos:
Command: mesos-slave --master=192.168.0.57:5050 --containerizers=mesos
 --hostname=192.168.0.57 --IP=192.168.0.57 --log_dir=/var/log/mesos
__
I0827 22:53:09.960764  3369 logging.cpp:142] INFO level logging started!
I0827 22:53:09.962329  3369 main.cpp:126] Build: 2014-08-22 05:05:59 by root
I0827 22:53:09.962749  3369 main.cpp:128] Version: 0.20.0
I0827 22:53:09.963065  3369 main.cpp:131] Git tag: 0.20.0
I0827 22:53:09.963369  3369 main.cpp:135] Git SHA:
f421ffdf8d32a8834b3a6ee483b5b59f65956497
I0827 22:53:09.963709  3369 containerizer.cpp:89] Using isolation:
posix/cpu,posix/mem
I0827 22:53:09.968011  3369 main.cpp:149] Starting Mesos slave
I0827 22:53:09.968703  3377 slave.cpp:167] Slave started on 1)@
192.168.0.57:5051
I0827 22:53:09.969319  3377 slave.cpp:278] Slave resources: cpus(*):2;
mem(*):15025; disk(*):26760; ports(*):[31000-32000]
I0827 22:53:09.969703  3377 slave.cpp:306] Slave hostname: 192.168.0.57
I0827 22:53:09.969912  3377 slave.cpp:307] Slave checkpoint: true
I0827 22:53:09.972486  3377 state.cpp:33] Recovering state from
'/tmp/mesos/meta'
I0827 22:53:09.972882  3377 state.cpp:62] Failed to find the latest slave
from '/tmp/mesos/meta'
I0827 22:53:09.973140  3377 status_update_manager.cpp:193] Recovering
status update manager
I0827 22:53:09.973368  3377 containerizer.cpp:252] Recovering containerizer
I0827 22:53:09.973819  3377 slave.cpp:3195] Finished recovery
I0827 22:53:09.974473  3377 slave.cpp:589] New master detected at
master@192.168.0.57:5050
I0827 22:53:09.974822  3370 status_update_manager.cpp:167] New master
detected at master@192.168.0.57:5050
I0827 22:53:09.974983  3377 slave.cpp:625] No credentials provided.
Attempting to register without authentication
I0827 22:53:09.975147  3377 slave.cpp:636] Detecting new master
I0827 22:53:10.758889  3374 slave.cpp:754] Registered with master
master@192.168.0.57:5050; given slave ID
20140827-224307-956344512-5050-3182-0
I0827 22:53:10.759145  3374 slave.cpp:767] Checkpointing SlaveInfo to
'/tmp/mesos/meta/slaves/20140827-224307-956344512-5050-3182-0/slave.info'

Thanks.
-- 
Javier

Mesos autoscaling script

[Michael Babineau]

I wrote a script to automatically launch/terminate Mesos slaves on EC2
based on available resources:
https://github.com/thefactory/autoscale-python/blob/master/examples/mesos_ec2.py

Scaling actions are performed by a provider-specific component, so
supporting Google Compute Engine or another provider is simply a matter of
implementing the same (trivial) interface. Same goes for incorporating
other data sources or custom scaling logic: just write a drop-in
replacement for an existing component.

I've started a Python library around this pattern. Current support
is...humble.. (only "Mesos based on disk/mem/cpu free on EC2"), but I'd
love to build out a suite of components to handle different use cases
(non-Mesos; non-EC2; alternative logic; etc). Please check it out:
https://github.com/thefactory/autoscale-python

Thanks to Connor Doyle for the early design feedback. If anybody else has
thoughts on how to improve it, I'd love to hear them!

Re: Docker Example Mesos 0.20?

[Benjamin Hindman]

The order does matter. Let me try and elaborate.

Each containerizer in the list is tried, one at a time, to launch the
container. If a containerizer does not support launching the kind of
container requested (i.e., a Docker container), then the next containerizer
is tried. So, if you did:

--containerizers=external,docker,mesos

And whatever external containerizer you're running supports launching
Docker containers then the DockerContainerizer will never be used (in fact,
if your external containerizer supports creating all kinds of containers
then none of the other containerizers will ever be used).

After 0.20.1 (or if you're running from trunk), the order shouldn't matter
if you're just using the 'mesos' and 'docker' containerizer:

--containerizers=mesos,docker
--containerizers=docker,mesos

*But the order will still matter if you also want to use the external
containerizer!*

Hope that helps.

Ben.


On Wed, Aug 27, 2014 at 10:37 AM, Tim Chen  wrote:

> Hi Frank,
>
> Yes, the order shouldn't matter. Sorry for the confusion.
>
> Tim
>
>
> On Wed, Aug 27, 2014 at 10:24 AM, Frank Hinek 
> wrote:
>
>> So if I’m reading this correctly the order shouldn’t matter if you are
>> running from trunk or the future 0.20.1 release?
>>
>>
>> On August 27, 2014 at 1:21:02 PM, Tim Chen (t...@mesosphere.io) wrote:
>>
>> Hi Vinod,
>>
>> Yes we realized that as well, the order affect the evaluation of the
>> containerizers but I see Mesos Containterizer will not launch if
>> ContainerInfo is set.
>>
>> Tim
>>
>>
>> On Wed, Aug 27, 2014 at 10:15 AM, Vinod Kone  wrote:
>>
>>>
>>>  On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle 
>>> wrote:
>>>
 The order they are listed is significant
>>>
>>>
>>> Why is the order important? Is it a Marathon restriction? IIUC, Mesos
>>> will pick the right* containerizer based on whether TaskInfo.ContainerInfo
>>> or ExecutorInfo.ContainerInfo is set.
>>>
>>> * there is currently a bug that depends on the order but that is already
>>> fixed on trunk and will be included in 0.20.1 release.
>>>
>>
>>
>

Re: Docker Example Mesos 0.20?

[Tim Chen]

Hi Frank,

Yes, the order shouldn't matter. Sorry for the confusion.

Tim


On Wed, Aug 27, 2014 at 10:24 AM, Frank Hinek  wrote:

> So if I’m reading this correctly the order shouldn’t matter if you are
> running from trunk or the future 0.20.1 release?
>
>
> On August 27, 2014 at 1:21:02 PM, Tim Chen (t...@mesosphere.io) wrote:
>
> Hi Vinod,
>
> Yes we realized that as well, the order affect the evaluation of the
> containerizers but I see Mesos Containterizer will not launch if
> ContainerInfo is set.
>
> Tim
>
>
> On Wed, Aug 27, 2014 at 10:15 AM, Vinod Kone  wrote:
>
>>
>>  On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle 
>> wrote:
>>
>>> The order they are listed is significant
>>
>>
>> Why is the order important? Is it a Marathon restriction? IIUC, Mesos
>> will pick the right* containerizer based on whether TaskInfo.ContainerInfo
>> or ExecutorInfo.ContainerInfo is set.
>>
>> * there is currently a bug that depends on the order but that is already
>> fixed on trunk and will be included in 0.20.1 release.
>>
>
>

Re: Docker Example Mesos 0.20?

[Frank Hinek]

So if I’m reading this correctly the order shouldn’t matter if you are running 
from trunk or the future 0.20.1 release?


On August 27, 2014 at 1:21:02 PM, Tim Chen (t...@mesosphere.io) wrote:

Hi Vinod,

Yes we realized that as well, the order affect the evaluation of the 
containerizers but I see Mesos Containterizer will not launch if ContainerInfo 
is set.

Tim


On Wed, Aug 27, 2014 at 10:15 AM, Vinod Kone  wrote:

On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle  wrote:
The order they are listed is significant

Why is the order important? Is it a Marathon restriction? IIUC, Mesos will pick 
the right* containerizer based on whether TaskInfo.ContainerInfo or 
ExecutorInfo.ContainerInfo is set.

* there is currently a bug that depends on the order but that is already fixed 
on trunk and will be included in 0.20.1 release.

Re: Docker Example Mesos 0.20?

[Tim Chen]

Hi Vinod,

Yes we realized that as well, the order affect the evaluation of the
containerizers but I see Mesos Containterizer will not launch if
ContainerInfo is set.

Tim


On Wed, Aug 27, 2014 at 10:15 AM, Vinod Kone  wrote:

>
> On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle 
> wrote:
>
>> The order they are listed is significant
>
>
> Why is the order important? Is it a Marathon restriction? IIUC, Mesos will
> pick the right* containerizer based on whether TaskInfo.ContainerInfo or
> ExecutorInfo.ContainerInfo is set.
>
> * there is currently a bug that depends on the order but that is already
> fixed on trunk and will be included in 0.20.1 release.
>

Re: Docker Example Mesos 0.20?

[Vinod Kone]

On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle  wrote:

> The order they are listed is significant


Why is the order important? Is it a Marathon restriction? IIUC, Mesos will
pick the right* containerizer based on whether TaskInfo.ContainerInfo or
ExecutorInfo.ContainerInfo is set.

* there is currently a bug that depends on the order but that is already
fixed on trunk and will be included in 0.20.1 release.

Re: Docker Example Mesos 0.20?

[Frank Hinek]

Thanks for pointing out the significance of the order, Connor.  Very good to 
know.


On August 27, 2014 at 12:15:07 PM, Connor Doyle (connor@gmail.com) wrote:

Hi Eran, that's correct. Mesos supports multiple containerizers now.  The order 
they are listed is significant; as listed the Docker containerizer will pass on 
the TaskInfo if the ContainerInfo is not set or if the container type is not 
DOCKER.
--
Connor

On Aug 27, 2014, at 9:09, Eran Chinthaka Withana  
wrote:

Thanks Frank for these instructions. I will have to wait for marathon release 
to use this (hopefully that will happen soon)

A n00b question from me here. I noticed that we can now set 
"--containerizers=docker,mesos". Does this mean mesos slaves will now support 
both docker type and old containers? If we don't mention "container" section in 
the marathon request[1], will it work using standard lxc?



{


  "container":
{


"type":

"DOCKER",


"docker":
{


  "image":

"libmesos/ubuntu"


}


  },


  "id":

"ubuntu",


  "instances":

"1",


  "cpus":

"0.5",


  "mem":

"128",


  "uris":
[],


  "cmd":

"while sleep 10; do date -u +%T; done"


}

Thanks,
Eran Chinthaka Withana


On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek  wrote:
Working here as well.  Thanks for the assist Tim!

Put together a post on the steps for my own reference: 
http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/


On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com) wrote:

Thanks Tim works great.  Cheers!


On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
Hi Ray,

Sorry the tutorial is not yet up to date too, once we have Marathon 0.7 
released the tutorial will be updated as well.

Here is one example for running the image:

{

    "id": "inky", 

    "container": {

        "docker": {

            "image": "mesosphere/inky"

        },

        "type": "DOCKER",

        "volumes": []

    },

    "args": ["hello"],

    "cpus": 0.2,

    "mem": 32.0,

    "instances": 1

}



You can also provide a "cmd" string as well.



Tim



On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez  wrote:
I'm running marathon HEAD 0.7.0 against mesos 0.20.0.

My mesos slaves are running with the command line flag 
--containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem

When trying to run the example listed here: 
http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the 
following in the sandbox stderr/stdout

stdout:

Shutting down

stderr:

I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826 18:12:48.985131 
28843 exec.cpp:379] Executor asked to shutdown




On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek  wrote:
Thanks for the tip!  Building Marathon from latest master at the moment to test.




On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:

Hi Frank,

Yes you need Marathon 0.7 which we are working on to release soon.

In the mean time if you want you can grab latest master to experiment with.

Thanks!

Tim


On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek  wrote:
I did run through that example but it fails every time.  Perhaps it is because 
Marathon 0.6.1 doesn’t yet support the new capabilities in Mesos 0.20.0.

curl -X POST -H "Content-Type: application/json" http://127.0.0.1:8080/v2/apps 
-d...@docker.json
nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254  1742 
slave.cpp:1002] Got assigned task ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 
for framework 20140826-170643-251789322-5050-1532-
I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task 
ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework 
20140826-170643-251789322-5050-1532-
I0826 17:23:25.073552  1736 docker.cpp:782] No container info found, skipping 
launch
I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task 
'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor 
ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework 
'20140826-170643-251789322-5050-1532-
E0826 17:23:25.074518  1742 slave.cpp:2491] Container 
'01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor 
'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework 
'20140826-170643-251789322-5050-1532-' failed to start: 
TaskInfo/ExecutorInfo not supported
E0826 17:23:25.074937  1742 slave.cpp:2577] Termination of executor 
'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework 
'20140826-170643-251789322-5050-1532-' failed: No container found
E0826 17:23:25.075564  1742 slave.cpp:2863] Failed to unmonitor container for 
executor ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework 
20140826-170643-251789322-5050-1532-: Not monitored
I0826 17:23:25.076370  1742 slave.cpp:2087] Handling status update TASK_FAILED 
(UUID: 0da7c07d-aeb3-4aa3-a457-0dfcf0243914) for task 
ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework 
20140826-170643-251789322-5050-1532- from @0.0.0.0:0
E0826 17:23:25.076938  1742 slave.cpp:2204] Failed to update resources for 
container 01966efd-

Re: Docker Example Mesos 0.20?

[Eran Chinthaka Withana]

Perfect, thanks Connor. Now really looking forward to get into 0.20 since I
had minor issues with deimos + mesos 0.19. Hopefully Marathon will do a
release soon.

Thanks,
Eran Chinthaka Withana


On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle  wrote:

> Hi Eran, that's correct. Mesos supports multiple containerizers now.  The
> order they are listed is significant; as listed the Docker containerizer
> will pass on the TaskInfo if the ContainerInfo is not set or if the
> container type is not DOCKER.
> --
> Connor
>
> On Aug 27, 2014, at 9:09, Eran Chinthaka Withana 
> wrote:
>
> Thanks Frank for these instructions. I will have to wait for marathon
> release to use this (hopefully that will happen soon)
>
> A n00b question from me here. I noticed that we can now set
> "--containerizers=docker,mesos". Does this mean mesos slaves will now
> support both docker type and old containers? If we don't mention
> "container" section in the marathon request[1], will it work using standard
> lxc?
>
> {
>"container": {
>  "type": "DOCKER",
>  "docker": {
>"image": "libmesos/ubuntu"
>  }
>},
>"id": "ubuntu",
>"instances": "1",
>"cpus": "0.5",
>"mem": "128",
>"uris": [],
>"cmd": "while sleep 10; do date -u +%T; done"
>  }
>
> Thanks,
> Eran Chinthaka Withana
>
>
> On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek 
> wrote:
>
>> Working here as well.  Thanks for the assist Tim!
>>
>> Put together a post on the steps for my own reference:
>> http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/
>>
>>
>> On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com)
>> wrote:
>>
>> Thanks Tim works great.  Cheers!
>>
>>
>> On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
>>
>>> Hi Ray,
>>>
>>> Sorry the tutorial is not yet up to date too, once we have Marathon 0.7
>>> released the tutorial will be updated as well.
>>>
>>> Here is one example for running the image:
>>>
>>>  {
>>>
>>> "id": "inky",
>>>
>>> "container": {
>>>
>>> "docker": {
>>>
>>> "image": "mesosphere/inky"
>>>
>>> },
>>>
>>> "type": "DOCKER",
>>>
>>> "volumes": []
>>>
>>> },
>>>
>>> "args": ["hello"],
>>>
>>> "cpus": 0.2,
>>>
>>> "mem": 32.0,
>>>
>>> "instances": 1
>>>
>>> }
>>>
>>>
>>> You can also provide a "cmd" string as well.
>>>
>>>
>>> Tim
>>>
>>>
>>> On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez 
>>> wrote:
>>>
 I'm running marathon HEAD 0.7.0 against mesos 0.20.0.

 My mesos slaves are running with the command line flag
 --containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem

 When trying to run the example listed here:
 http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the
 following in the sandbox stderr/stdout

 stdout:

 Shutting down

 stderr:

 I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826
 18:12:48.985131 28843 exec.cpp:379] Executor asked to shutdown




 On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek 
 wrote:

>  Thanks for the tip!  Building Marathon from latest master at the
> moment to test.
>
>
>
>
> On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:
>
>  Hi Frank,
>
> Yes you need Marathon 0.7 which we are working on to release soon.
>
> In the mean time if you want you can grab latest master to experiment
> with.
>
> Thanks!
>
> Tim
>
>
> On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek 
> wrote:
>
>>  I did run through that example but it fails every time.  Perhaps it
>> is because Marathon 0.6.1 doesn’t yet support the new capabilities in 
>> Mesos
>> 0.20.0.
>>
>>  curl -X POST -H "Content-Type: application/json"
>> http://127.0.0.1:8080/v2/apps -d...@docker.json
>> nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254
>>  1742 slave.cpp:1002] Got assigned task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
>> 20140826-170643-251789322-5050-1532-
>> I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
>> 20140826-170643-251789322-5050-1532-
>> I0826 17:23:25.073552  1736 docker.cpp:782] No container info found,
>> skipping launch
>> I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task
>> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
>> '20140826-170643-251789322-5050-1532-
>> E0826 17:23:25.074518  1742 slave.cpp:2491] Container
>> '01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor
>> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
>> '20140826-170643-251789322-5050-1532-' failed to start:
>> TaskInfo/ExecutorInfo not supported
>> E0826 17:23:25.074937

Re: Docker Example Mesos 0.20?

[Connor Doyle]

Hi Eran, that's correct. Mesos supports multiple containerizers now.  The order 
they are listed is significant; as listed the Docker containerizer will pass on 
the TaskInfo if the ContainerInfo is not set or if the container type is not 
DOCKER.
--
Connor

> On Aug 27, 2014, at 9:09, Eran Chinthaka Withana  
> wrote:
> 
> Thanks Frank for these instructions. I will have to wait for marathon release 
> to use this (hopefully that will happen soon)
> 
> A n00b question from me here. I noticed that we can now set 
> "--containerizers=docker,mesos". Does this mean mesos slaves will now support 
> both docker type and old containers? If we don't mention "container" section 
> in the marathon request[1], will it work using standard lxc?
> 
> 
> {
> 
>   "container": {
> 
> "type": "DOCKER",
> 
> "docker": {
> 
>   "image": "libmesos/ubuntu"
> 
> }
> 
>   },
> 
>   "id": "ubuntu",
> 
>   "instances": "1",
> 
>   "cpus": "0.5",
> 
>   "mem": "128",
> 
>   "uris": [],
> 
>   "cmd": "while sleep 10; do date -u +%T; done"
> 
> }
> 
> Thanks,
> Eran Chinthaka Withana
> 
> 
>> On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek  wrote:
>> Working here as well.  Thanks for the assist Tim!
>> 
>> Put together a post on the steps for my own reference: 
>> http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/
>> 
>> 
>>> On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com) 
>>> wrote:
>>> 
>>> Thanks Tim works great.  Cheers!
>>> 
>>> 
 On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
 Hi Ray,
 
 Sorry the tutorial is not yet up to date too, once we have Marathon 0.7 
 released the tutorial will be updated as well.
 
 Here is one example for running the image:
 
 {
 
 "id": "inky", 
 
 "container": {
 
 "docker": {
 
 "image": "mesosphere/inky"
 
 },
 
 "type": "DOCKER",
 
 "volumes": []
 
 },
 
 "args": ["hello"],
 
 "cpus": 0.2,
 
 "mem": 32.0,
 
 "instances": 1
 
 }
 
 
 
 You can also provide a "cmd" string as well.
 
 
 
 Tim
 
 
 
> On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez  
> wrote:
> I'm running marathon HEAD 0.7.0 against mesos 0.20.0.
> 
> My mesos slaves are running with the command line flag 
> --containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem
> 
> When trying to run the example listed here: 
> http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the 
> following in the sandbox stderr/stdout
> 
> stdout:
> 
> Shutting down
> 
> stderr:
> 
> I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826 
> 18:12:48.985131 28843 exec.cpp:379] Executor asked to shutdown
> 
> 
> 
> 
>> On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek  
>> wrote:
>> Thanks for the tip!  Building Marathon from latest master at the moment 
>> to test.
>> 
>> 
>> 
>> 
>>> On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:
>>> 
>>> Hi Frank,
>>> 
>>> Yes you need Marathon 0.7 which we are working on to release soon.
>>> 
>>> In the mean time if you want you can grab latest master to experiment 
>>> with.
>>> 
>>> Thanks!
>>> 
>>> Tim
>>> 
>>> 
 On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek  
 wrote:
 I did run through that example but it fails every time.  Perhaps it is 
 because Marathon 0.6.1 doesn’t yet support the new capabilities in 
 Mesos 0.20.0.
 
 curl -X POST -H "Content-Type: application/json" 
 http://127.0.0.1:8080/v2/apps -d...@docker.json
 nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254  1742 
 slave.cpp:1002] Got assigned task 
 ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework 
 20140826-170643-251789322-5050-1532-
 I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task 
 ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework 
 20140826-170643-251789322-5050-1532-
 I0826 17:23:25.073552  1736 docker.cpp:782] No container info found, 
 skipping launch
 I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task 
 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor 
 ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework 
 '20140826-170643-251789322-5050-1532-
 E0826 17:23:25.074518  1742 slave.cpp:2491] Container 
 '01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor 
 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework 
 '20140826-170643-251789322-5050-1532-' failed to start: 
 TaskInfo/ExecutorInfo not supported
 E0826 17:23:

Re: Docker Example Mesos 0.20?

[Eran Chinthaka Withana]

Thanks Frank for these instructions. I will have to wait for marathon
release to use this (hopefully that will happen soon)

A n00b question from me here. I noticed that we can now set
"--containerizers=docker,mesos". Does this mean mesos slaves will now
support both docker type and old containers? If we don't mention
"container" section in the marathon request[1], will it work using standard
lxc?

{
  "container": {
"type": "DOCKER",
"docker": {
  "image": "libmesos/ubuntu"
}
  },
  "id": "ubuntu",
  "instances": "1",
  "cpus": "0.5",
  "mem": "128",
  "uris": [],
  "cmd": "while sleep 10; do date -u +%T; done"
}

Thanks,
Eran Chinthaka Withana


On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek  wrote:

> Working here as well.  Thanks for the assist Tim!
>
> Put together a post on the steps for my own reference:
> http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/
>
>
> On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com)
> wrote:
>
> Thanks Tim works great.  Cheers!
>
>
> On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
>
>> Hi Ray,
>>
>> Sorry the tutorial is not yet up to date too, once we have Marathon 0.7
>> released the tutorial will be updated as well.
>>
>> Here is one example for running the image:
>>
>>  {
>>
>> "id": "inky",
>>
>> "container": {
>>
>> "docker": {
>>
>> "image": "mesosphere/inky"
>>
>> },
>>
>> "type": "DOCKER",
>>
>> "volumes": []
>>
>> },
>>
>> "args": ["hello"],
>>
>> "cpus": 0.2,
>>
>> "mem": 32.0,
>>
>> "instances": 1
>>
>> }
>>
>>
>> You can also provide a "cmd" string as well.
>>
>>
>> Tim
>>
>>
>> On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez 
>> wrote:
>>
>>> I'm running marathon HEAD 0.7.0 against mesos 0.20.0.
>>>
>>> My mesos slaves are running with the command line flag
>>> --containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem
>>>
>>> When trying to run the example listed here:
>>> http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the
>>> following in the sandbox stderr/stdout
>>>
>>> stdout:
>>>
>>> Shutting down
>>>
>>> stderr:
>>>
>>> I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826
>>> 18:12:48.985131 28843 exec.cpp:379] Executor asked to shutdown
>>>
>>>
>>>
>>>
>>> On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek 
>>> wrote:
>>>
  Thanks for the tip!  Building Marathon from latest master at the
 moment to test.




 On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:

  Hi Frank,

 Yes you need Marathon 0.7 which we are working on to release soon.

 In the mean time if you want you can grab latest master to experiment
 with.

 Thanks!

 Tim


 On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek 
 wrote:

>  I did run through that example but it fails every time.  Perhaps it
> is because Marathon 0.6.1 doesn’t yet support the new capabilities in 
> Mesos
> 0.20.0.
>
>  curl -X POST -H "Content-Type: application/json"
> http://127.0.0.1:8080/v2/apps -d...@docker.json
> nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254
>  1742 slave.cpp:1002] Got assigned task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
> 20140826-170643-251789322-5050-1532-
> I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
> 20140826-170643-251789322-5050-1532-
> I0826 17:23:25.073552  1736 docker.cpp:782] No container info found,
> skipping launch
> I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
> '20140826-170643-251789322-5050-1532-
> E0826 17:23:25.074518  1742 slave.cpp:2491] Container
> '01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
> '20140826-170643-251789322-5050-1532-' failed to start:
> TaskInfo/ExecutorInfo not supported
> E0826 17:23:25.074937  1742 slave.cpp:2577] Termination of executor
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
> '20140826-170643-251789322-5050-1532-' failed: No container found
> E0826 17:23:25.075564  1742 slave.cpp:2863] Failed to unmonitor
> container for executor ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of
> framework 20140826-170643-251789322-5050-1532-: Not monitored
> I0826 17:23:25.076370  1742 slave.cpp:2087] Handling status update
> TASK_FAILED (UUID: 0da7c07d-aeb3-4aa3-a457-0dfcf0243914) for task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
> 20140826-170643-251789322-5050-1532- from @0.0.0.0:0
> E0826 17:23:25.076938  1742 slave.cpp:2204] Failed to update resources
> for container 01966efd-f

Re: Migration from mesos 0.19 to mesos 0.20

[Vinod Kone]

See docs/upgrades.md. 

@vinodkone

> On Aug 27, 2014, at 5:48 AM, Giulio Eulisse  wrote:
> 
> Hi,
> 
> is there any best practices / recommendation when updating from mesos 0.19 to 
> mesos 0.20?
> 
> -- 
> Ciao,
> Giulio

Migration from mesos 0.19 to mesos 0.20

[Giulio Eulisse]

Hi,

is there any best practices / recommendation when updating from mesos 
0.19 to mesos 0.20?


--
Ciao,
Giulio

Re: Docker Example Mesos 0.20?

[Dick Davies]

Really excited to see this at last! Do we have an ETA for releases of
marathon+mesos to
support this?

On 27 August 2014 09:11, Connor Doyle  wrote:
> See also Docker/Mesos/Marathon this doc, hot off the presses:
> https://mesosphere.github.io/marathon/docs/native-docker.html
> --
> Connor
>
> On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek  wrote:
>> Working here as well.  Thanks for the assist Tim!
>>
>> Put together a post on the steps for my own reference:
>> http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/
>>
>>
>> On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com)
>> wrote:
>>
>> Thanks Tim works great.  Cheers!
>>
>>
>> On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
>>>
>>> Hi Ray,
>>>
>>> Sorry the tutorial is not yet up to date too, once we have Marathon 0.7
>>> released the tutorial will be updated as well.
>>>
>>> Here is one example for running the image:
>>>
>>> {
>>>
>>> "id": "inky",
>>>
>>> "container": {
>>>
>>> "docker": {
>>>
>>> "image": "mesosphere/inky"
>>>
>>> },
>>>
>>> "type": "DOCKER",
>>>
>>> "volumes": []
>>>
>>> },
>>>
>>> "args": ["hello"],
>>>
>>> "cpus": 0.2,
>>>
>>> "mem": 32.0,
>>>
>>> "instances": 1
>>>
>>> }
>>>
>>>
>>> You can also provide a "cmd" string as well.
>>>
>>>
>>> Tim
>>>
>>>
>>>
>>> On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez 
>>> wrote:

 I'm running marathon HEAD 0.7.0 against mesos 0.20.0.

 My mesos slaves are running with the command line flag
 --containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem

 When trying to run the example listed here:
 http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the
 following in the sandbox stderr/stdout

 stdout:

 Shutting down

 stderr:

 I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826
 18:12:48.985131 28843 exec.cpp:379] Executor asked to shutdown




 On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek 
 wrote:
>
> Thanks for the tip!  Building Marathon from latest master at the moment
> to test.
>
>
>
>
> On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:
>
> Hi Frank,
>
> Yes you need Marathon 0.7 which we are working on to release soon.
>
> In the mean time if you want you can grab latest master to experiment
> with.
>
> Thanks!
>
> Tim
>
>
> On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek 
> wrote:
>>
>> I did run through that example but it fails every time.  Perhaps it is
>> because Marathon 0.6.1 doesn’t yet support the new capabilities in Mesos
>> 0.20.0.
>>
>> curl -X POST -H "Content-Type: application/json"
>> http://127.0.0.1:8080/v2/apps -d...@docker.json
>> nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254  1742
>> slave.cpp:1002] Got assigned task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
>> 20140826-170643-251789322-5050-1532-
>> I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
>> 20140826-170643-251789322-5050-1532-
>> I0826 17:23:25.073552  1736 docker.cpp:782] No container info found,
>> skipping launch
>> I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task
>> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
>> '20140826-170643-251789322-5050-1532-
>> E0826 17:23:25.074518  1742 slave.cpp:2491] Container
>> '01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor
>> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
>> '20140826-170643-251789322-5050-1532-' failed to start:
>> TaskInfo/ExecutorInfo not supported
>> E0826 17:23:25.074937  1742 slave.cpp:2577] Termination of executor
>> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
>> '20140826-170643-251789322-5050-1532-' failed: No container found
>> E0826 17:23:25.075564  1742 slave.cpp:2863] Failed to unmonitor
>> container for executor ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of
>> framework 20140826-170643-251789322-5050-1532-: Not monitored
>> I0826 17:23:25.076370  1742 slave.cpp:2087] Handling status update
>> TASK_FAILED (UUID: 0da7c07d-aeb3-4aa3-a457-0dfcf0243914) for task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
>> 20140826-170643-251789322-5050-1532- from @0.0.0.0:0
>> E0826 17:23:25.076938  1742 slave.cpp:2204] Failed to update resources
>> for container 01966efd-f521-4f54-87e4-f84aa9adcfa9 of executor
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 running task
>> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 on status update for terminal
>> task, destroying container: No container found
>>

Re: Docker Example Mesos 0.20?

[Connor Doyle]

See also Docker/Mesos/Marathon this doc, hot off the presses:
https://mesosphere.github.io/marathon/docs/native-docker.html
--
Connor

On Tue, Aug 26, 2014 at 11:06 PM, Frank Hinek  wrote:
> Working here as well.  Thanks for the assist Tim!
>
> Put together a post on the steps for my own reference:
> http://frankhinek.com/deploy-docker-containers-on-mesos-0-20/
>
>
> On August 26, 2014 at 4:39:38 PM, Ray Rodriguez (rayrod2...@gmail.com)
> wrote:
>
> Thanks Tim works great.  Cheers!
>
>
> On Tue, Aug 26, 2014 at 4:31 PM, Tim Chen  wrote:
>>
>> Hi Ray,
>>
>> Sorry the tutorial is not yet up to date too, once we have Marathon 0.7
>> released the tutorial will be updated as well.
>>
>> Here is one example for running the image:
>>
>> {
>>
>> "id": "inky",
>>
>> "container": {
>>
>> "docker": {
>>
>> "image": "mesosphere/inky"
>>
>> },
>>
>> "type": "DOCKER",
>>
>> "volumes": []
>>
>> },
>>
>> "args": ["hello"],
>>
>> "cpus": 0.2,
>>
>> "mem": 32.0,
>>
>> "instances": 1
>>
>> }
>>
>>
>> You can also provide a "cmd" string as well.
>>
>>
>> Tim
>>
>>
>>
>> On Tue, Aug 26, 2014 at 11:28 AM, Ray Rodriguez 
>> wrote:
>>>
>>> I'm running marathon HEAD 0.7.0 against mesos 0.20.0.
>>>
>>> My mesos slaves are running with the command line flag
>>> --containerizers=docker,mesos and --isolation=cgroups/cpu,cgroups/mem
>>>
>>> When trying to run the example listed here:
>>> http://mesosphere.io/learn/run-docker-on-mesosphere-cluster/ I get the
>>> following in the sandbox stderr/stdout
>>>
>>> stdout:
>>>
>>> Shutting down
>>>
>>> stderr:
>>>
>>> I0826 18:12:48.983397 28817 exec.cpp:132] Version: 0.20.0 I0826
>>> 18:12:48.985131 28843 exec.cpp:379] Executor asked to shutdown
>>>
>>>
>>>
>>>
>>> On Tue, Aug 26, 2014 at 2:15 PM, Frank Hinek 
>>> wrote:

 Thanks for the tip!  Building Marathon from latest master at the moment
 to test.




 On August 26, 2014 at 1:47:20 PM, Tim Chen (t...@mesosphere.io) wrote:

 Hi Frank,

 Yes you need Marathon 0.7 which we are working on to release soon.

 In the mean time if you want you can grab latest master to experiment
 with.

 Thanks!

 Tim


 On Tue, Aug 26, 2014 at 10:41 AM, Frank Hinek 
 wrote:
>
> I did run through that example but it fails every time.  Perhaps it is
> because Marathon 0.6.1 doesn’t yet support the new capabilities in Mesos
> 0.20.0.
>
> curl -X POST -H "Content-Type: application/json"
> http://127.0.0.1:8080/v2/apps -d...@docker.json
> nullvagrant@vagrant-ubuntu-trusty-64:/tmp$ I0826 17:23:25.071254  1742
> slave.cpp:1002] Got assigned task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
> 20140826-170643-251789322-5050-1532-
> I0826 17:23:25.072319  1742 slave.cpp:1112] Launching task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 for framework
> 20140826-170643-251789322-5050-1532-
> I0826 17:23:25.073552  1736 docker.cpp:782] No container info found,
> skipping launch
> I0826 17:23:25.074030  1742 slave.cpp:1222] Queuing task
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' for executor
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
> '20140826-170643-251789322-5050-1532-
> E0826 17:23:25.074518  1742 slave.cpp:2491] Container
> '01966efd-f521-4f54-87e4-f84aa9adcfa9' for executor
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
> '20140826-170643-251789322-5050-1532-' failed to start:
> TaskInfo/ExecutorInfo not supported
> E0826 17:23:25.074937  1742 slave.cpp:2577] Termination of executor
> 'ubuntu.afa18986-2d45-11e4-8e47-56847afe9799' of framework
> '20140826-170643-251789322-5050-1532-' failed: No container found
> E0826 17:23:25.075564  1742 slave.cpp:2863] Failed to unmonitor
> container for executor ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of
> framework 20140826-170643-251789322-5050-1532-: Not monitored
> I0826 17:23:25.076370  1742 slave.cpp:2087] Handling status update
> TASK_FAILED (UUID: 0da7c07d-aeb3-4aa3-a457-0dfcf0243914) for task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
> 20140826-170643-251789322-5050-1532- from @0.0.0.0:0
> E0826 17:23:25.076938  1742 slave.cpp:2204] Failed to update resources
> for container 01966efd-f521-4f54-87e4-f84aa9adcfa9 of executor
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 running task
> ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 on status update for terminal
> task, destroying container: No container found
> I0826 17:23:25.077309  1737 status_update_manager.cpp:320] Received
> status update TASK_FAILED (UUID: 0da7c07d-aeb3-4aa3-a457-0dfcf0243914) for
> task ubuntu.afa18986-2d45-11e4-8e47-56847afe9799 of framework
> 20140826-170643-251789322-5050-1532-
> I0826 17:23:25.077424  1737 stat