RE: Mesos working groups
The existence of working groups on external volume and global resource still makes sense to me From: Jie Yu [mailto:yujie@gmail.com] Sent: Thursday, June 16, 2016 11:00 AM To: mesos; user@mesos.apache.org Subject: Mesos working groups Hi, I am in the process of formalizing our working groups. We recently moved our working groups wiki to documentation in the repo (Thanks Tomasz!). That'll give us more visibility hopefully. https://github.com/apache/mesos/blob/master/docs/working-groups.md However, I realized that a lot of the working groups listed above are no longer active, or does not make sense anymore. Could you please reply to this thread if you think the working group is still valid. I'll remove the rest. Thanks! - Jie
RE: Deploying MySQL and WordPress Docker Containers through Marathon
There was a presentation given on this last week at the EMC World conference,
demonstrating migration of a MySQL server across cluster nodes, with persistent
storage on an external volume. For this use case, a cloud volume (such as AWS
EBS), or a networked attached storage volume (such as ScaleIO) would be used to
hold the database.
slide deck:
http://www.slideshare.net/EMCCODE/emc-world-2016-code04-extending-mesos-for-storage-and-external-resources
Video of demo:
https://www.youtube.com/watch?v=DL64mdYv5Lg=PLbssOJyyvHuWiBQAg9EFWH570timj2fxt=1
Note that the demo is using a very recent version of the DC/OS Marathon UI
Steve Wong
Developer Advocate
EMC{code} - the open source advocacy group within EMC
[emccode small]
CODE OPEN, DEPLOY EVERYWHERE
https://github.com/emccode
blog.emccode.com
@cantbewong
From: suruchi.kum...@accenture.com [mailto:suruchi.kum...@accenture.com]
Sent: Thursday, May 12, 2016 2:59 AM
To: user@mesos.apache.org
Subject: Deploying MySQL and WordPress Docker Containers through Marathon
Hi ,
In case we are killing one of the instances running through Marathon UI. It is
able to bring up another replacing it.
So, would like to know is it a replication of the previous instance which was
killed or it's a new one.
For example, if we are running a MySQL application through Marathon UI and try
on of its instance to kill. Will the information saved in the database will be
remain in the new one replacing it.
Thanks
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise confidential information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the e-mail by you is prohibited. Where allowed by local law, electronic
communications with Accenture and its affiliates, including e-mail and instant
messaging (including content), may be scanned by our systems for the purposes
of information security and assessment of internal compliance with Accenture
policy.
__
www.accenture.com
RE: external storage with dvdi module
Storage providers fall into two categories, those that explicitly have
architected API support for pre-emptive mount and those that require custom
coding and orchestration.
I anticipate that OpenStack cinder will be supported for pre-emptive mount.
Another consideration: if the scenario is not Mesos agent shutdown or crash,
but instead a network partitioning event. Wihere the agent cluster node
continues t run, but is seen as equivalent to a crash by the Mesos Master, the
OpenStack cinder volume will be abruptly "torn away" from the original mounter.
Should this occur midstream during a write, there is the possibility that it
would result in some form of data corruption.
I expect that OpenStack cinder pre-emptive mount will be delivered in the next
major release of the rexray driver along with Amazon EBS pre-emptive mounts and
others TBD.
I will update the issue on github with the list of expected storage providers
as I get closer to delivery.
Steve Wong
Contributor to the Mesos dvdi module project
Developer Advocate
EMC{code} - the open source advocacy group within EMC
CODE OPEN, DEPLOY EVERYWHERE
https://github.com/emccode
blog.emccode.com
1.562.417.7048
steven.w...@emc.com<mailto:steven.w...@emc.com>
@cantbewong
From: Marica Antonacci [mailto:marica.antona...@ba.infn.it]
Sent: Friday, November 20, 2015 12:44 AM
To: Wong, Steven
Subject: Re: external storage with dvdi module
Dear Steven,
thank you very much for your detailed reply; I think that pre-emptive mount
capability will be certainly a valuable addition.
As far as I understand, this feature will depend mainly on the underlying
storage layer and will work only if a related capability is exposed by the
storage component itself. For example, concerning Openstack Cinder the
pre-emptive mount is not currently supported and there is a blueprint (approved
but not implemented yet) for enabling the multiple attachments of a single
volume. The roadmap for such addition in cinder is not clear to me yet...what
will be the behavior of the dvdi module (and the openstack storage driver) in
the meanwhile?
...
RE: Re: external storage with dvdi module
Regarding inquiry by Marica Antonacci on Wed, 18 Nov 2015 04:43:47 -0800
Failover scenarios are anticipated in the DVDI module and are being tracked as
this issue on github
https://github.com/emccode/mesos-module-dvdi/issues/23
The resolution of this issue requires that the underlying volume driver
supports a "pre-emptive mount" whereby any prior mounts are terminated
automatically by a mount from another node.
Many but not all storage providers are capable of supporting this behavior.
The intention is that DVDI will handle scenarios including:
1. Task crashes on an agent node and is rescheduled on a different node. Note
in this case, if the slave process remains running, it is very likely that the
dvdi module will remove the mount automatically now. However this might not
occur BEFORE the task is rescheduled on another cluster node, so the upcoming
pre-emptive mount feature could be useful in this scenario.
2. Entire Agent node crashes while task is running and does not restart or
return. The agent machine is a smoking piece of molten metal. This will REQUIRE
the new dvdi feature and support from the underlying storage driver.
3. Agent crashes and restarts. Similar to scenario #1 but perhaps the unmounts
takes longer. This scenario should result in removal of the original mount upon
restart, and is implemented now. If the Agent restart takes a long time, the
roadmap pre-emptive mount feature will be of value.
As a related note, some storage providers and some filesystems actually allow
use of concurrent mounts from multiple cluster nodes, although this is
uncommon. The architecture of the dvdi module is intended to support this,
although no volume driver available today enable the functionality.
In summary pre-emptive mount is a roadmap feature for the dvdi module. I expect
it to be delivered shortly, after the feature is enabled in the rexray driver.
My best guess is that this will not occur within the next two weeks, but it may
occur within the next two months.
Steve Wong
Contributor to the Mesos dvdi module project Developer Advocate EMC{code} - the
open source advocacy group within EMC
CODE OPEN, DEPLOY EVERYWHERE
https://github.com/emccode
blog.emccode.com
1.562.417.7048
steven.w...@emc.com
@cantbewong
