[
https://issues.apache.org/jira/browse/MAPREDUCE-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413337#comment-13413337
]
Kihwal Lee commented on MAPREDUCE-4393:
---------------------------------------
I didn't mean that the manager AM is responsible for launching app AMs. I think
it can be a separate yarn app. They don't even have to be any start-up
dependency among them, if we design communication protocol well. This also
makes restart easy.
If we can (re)launch the manager AM on one of the predefined set of hosts, most
of the requirements can be met. By storing system state in the hdfs and
reading back on restart, it can go back in sync fast and offer service again.
Routers can be provisioned similarly, but they will acquire state information
from the manager AM. The service discovery is simplified by the fact that they
will be on specific hosts. If a VIP is used to deal with service up/down or
migration among the given set of hosts, the service discovery is further
simplified. Since they are independent app instances or independent yarn apps,
a crash/restart of one thing won't force termination of others.
The one thing I am not sure about is the ability to specifying a specific set
of candidate hosts for launching AM. If not supported already, we can launch AM
on a random host and then launch containers on a specific set of hosts, but
that lowers the reliability. Or maybe the AM can be anywhere and the container
launched from it will only be used for service discovery.
I am not insisting on doing this now, but it will be nice if everything is
contained in YARN so that setting up is simpler and it is easily demoable.
> PaaS on YARN: an YARN application to demonstrate that YARN can be used as a
> PaaS
> --------------------------------------------------------------------------------
>
> Key: MAPREDUCE-4393
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4393
> Project: Hadoop Map/Reduce
> Issue Type: Task
> Components: examples
> Affects Versions: 0.23.1
> Reporter: Jaigak Song
> Assignee: Jaigak Song
> Fix For: 3.0.0
>
> Attachments: HADOOPasPAAS_Architecture.pdf, MAPREDUCE-4393.patch,
> MAPREDUCE-4393.patch, MAPREDUCE-4393.patch, MAPREDUCE4393.patch,
> MAPREDUCE4393.patch
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> This application is to demonstrate that YARN can be used for non-mapreduce
> applications. As Hadoop has already been adopted and deployed widely and its
> deployment in future will be highly increased, we thought that it's a good
> potential to be used as PaaS.
> I have implemented a proof of concept to demonstrate that YARN can be used as
> a PaaS (Platform as a Service). I have done a gap analysis against VMware's
> Cloud Foundry and tried to achieve as many PaaS functionalities as possible
> on YARN.
> I'd like to check in this POC as a YARN example application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
