<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That would make things much simpler, from Falkon's perspective.
Essentially, if the workspace service offered an interface that Falkon
to allocate and de-allocate resources (VMs) on demand, then the Falkon
dynamic resource provisioning could be used as long as Falkon implement
this new workspace interface instead of the current GRAM interface it
uses! Then, the whole EC2 deployment and bootstrapping would be
offloaded to the worspace service, and only the resource provisioning
and task dispatch would be done at Falkon, the same as it is today when
we use GRAM!<br>
<br>
Ioan<br>
<br>
Yong Zhao wrote:
<blockquote
cite="mid:Pine.LNX.4.58.0705161233520.3799@classes.cs.uchicago.edu"
type="cite">
<pre wrap="">I'd think the the workspace manager should be able to do that, and not
statically, but allocate new virtual nodes as requested.
Yong.
On Wed, 16 May 2007, Ioan Raicu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Well, the dynamic provisioning assumes that Falkon is acquiring
resources when it needs them. This implies that it knows how to talk to
the EC2 service, and it knows how to bootstrap a VM that has the
necessary Falkon software stack.
I was actually hoping (at least in the short term) that static resource
provisioning could be handled by the workspace service, talking to the
EC2 service and bootstraping the VM (with the necesarry Falkon stack),
and then once the Falkon executors register with the Falkon dispatcher,
then Falkon handles the lightweight job management (in place of a
traditional LRM).
The provisioning to EC2 could be pushed onto Falkon in the future, but
it is not currently on my immediate list of things to-do list.
Ioan
Kate Keahey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks Ben, this helps a lot! So it seems to me like we are talking
about combining dynamic provisioning with lightweight job management
which should be pluggable into swift.
Ben Clifford wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 15 May 2007, Kate Keahey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">As Ian says, Borja and I were planning to meet with Ioan on Thursday
to discuss interaction between Falkon and the workspace service (not
necessarily/exclusively in the EC2 context). I don't completely
understand the relationship between swift and falkon -- are there
specific applications or scenarios that you are trying to target in
this exercise?
</pre>
</blockquote>
<pre wrap="">By virtue of the fact that they come from pretty much the same group
of people, they're somewhat fuzzily related - but pretty much swift
is generating (over the duration of its execution, rather than in one
batch) a bunch of jobs that need executing (as well, as various
things like file transfers). As it generates them, it sends them off
to be executed. The official ways that are 'supported' by Swift are
by executing them on the local machine and by sending them off
through GRAM; however, people can plug in whatever they want to do
submissions.
I know less about Falkon because it isn't Swift, but the Falkon side
of things is pretty much about running a bunch of jobs - it plugs
into the abovementioned place in Swift so that Swift gives Falkon
jobs to run, and Falkon runs them (with a goal of Falkon being,
presumably, to run it much more efficiently than if they were
submitted straight through GRAM - it seems to do pretty well).
There's two things going on with swift - one is about making it
straightforward to use at the low end of things, so that people can
start using it easily - for the most part, that isn't interesting in
itself; the other is about getting it to perform well at the high end
of things, which is where the fun research is. Using Falkon and using
EC2 are both on that side of things.
</pre>
</blockquote>
</blockquote>
<pre wrap="">--
============================================
Ioan Raicu
Ph.D. Student
============================================
Distributed Systems Laboratory
Computer Science Department
University of Chicago
1100 E. 58th Street, Ryerson Hall
Chicago, IL 60637
============================================
Email: <a class="moz-txt-link-abbreviated" href="mailto:iraicu@cs.uchicago.edu">iraicu@cs.uchicago.edu</a>
Web: <a class="moz-txt-link-freetext" href="http://www.cs.uchicago.edu/~iraicu">http://www.cs.uchicago.edu/~iraicu</a>
<a class="moz-txt-link-freetext" href="http://dsl.cs.uchicago.edu/">http://dsl.cs.uchicago.edu/</a>
============================================
============================================
_______________________________________________
Swift-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a>
<a class="moz-txt-link-freetext" href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
============================================
Ioan Raicu
Ph.D. Student
============================================
Distributed Systems Laboratory
Computer Science Department
University of Chicago
1100 E. 58th Street, Ryerson Hall
Chicago, IL 60637
============================================
Email: <a class="moz-txt-link-abbreviated" href="mailto:iraicu@cs.uchicago.edu">iraicu@cs.uchicago.edu</a>
Web: <a class="moz-txt-link-freetext" href="http://www.cs.uchicago.edu/~iraicu">http://www.cs.uchicago.edu/~iraicu</a>
<a class="moz-txt-link-freetext" href="http://dsl.cs.uchicago.edu/">http://dsl.cs.uchicago.edu/</a>
============================================
============================================
</pre>
</body>
</html>