Re: [MTT devel] GSOC application

[Jeff Squyres]

I did specifically ask for dancing bears.  ;-)

On Apr 22, 2009, at 10:58 AM, Ethan Mallove wrote:


Dancing bears on slide 1. We're off to a good start.

-Ethan

On Wed, Apr/22/2009 09:11:57AM, Jeff Squyres wrote:
> The slides will also be on webex on the call tomorrow.  Use the  
URL to join
> the meeting in the email invite that you got.  That URL will  
launch an
> application thingy for the web portion of the meeting, and it will  
prompt

> you for a phone number to call you to join the audio portion of the
> meeting.  Mike will be transmitting his slides on the web portion  
(just

> because we can / it's fun ;-) ).
>
>
> On Apr 22, 2009, at 8:39 AM, Mike Dubman wrote:
>
>> Hello guys,
>>
>> Here is a small ppt with MTToGDS summary for tomorrow`s meeting.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 5:02 PM, Jeff Squyres  
 wrote:
>> Will there be dancing bears on the slides?  I'll only accept  
slides with

>> dancing bears!
>>
>> ;-)
>>
>> (no need to be formal; if slides help, great, otherwise don't  
make slides

>> just because we have webex available)
>>
>>
>>
>> On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:
>>
>> I will prepare ppt with summary of what were discussed and agreed,
>> milestones, open questions and other thoughts.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres  
 wrote:
>> Ok, I think we converged on a time: 9am US Eastern / 4pm Israel  
next

>> Thuesday, April 23.
>>
>> I'll send the webex invites in a separate email.  Mike: if you  
have slides
>> or other electronic material to show during the call, we can use  
webex for
>> that.  Otherwise, we can just use the telephone part of webex and  
ignore

>> the web part.
>>
>>
>>
>> On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:
>>
>> I have been listening in on the thread, but have not had time to
>> really look at much (which is why I have not been replying). I'm
>> interested in listening in on the teleconf as well, though if I  
become

>> a blocker for finding a time feel free to cut me out.
>>
>> Best,
>> Josh
>>
>> On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:
>>
>> >> BTW -- if it's useful to have a teleconference about this kind  
of
>> >> stuff, I can host a WebEx meeting.  WebEx has local dialins  
around

>> >> the world, including Israel...
>> >>
>> >>
>> >> sure, what about next week?
>> >
>> > I have a Doodle account -- let's try that to do the scheduling:
>> >
>> >http://doodle.com/gzpgaun2ef4szt29
>> >
>> > Ethan, Josh, and I are all in US Eastern timezone (I don't know  
if

>> > Josh will participate), so that might make scheduling *slightly*
>> > easier.  I started timeslots at 8am US Eastern and stopped as  
2pm US
>> > Eastern -- that's already pretty late in Israel.  I also didn't  
list

>> > Friday, since that's the weekend in Israel.
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Ethan Mallove]

Dancing bears on slide 1. We're off to a good start.

-Ethan

On Wed, Apr/22/2009 09:11:57AM, Jeff Squyres wrote:
> The slides will also be on webex on the call tomorrow.  Use the URL to join 
> the meeting in the email invite that you got.  That URL will launch an 
> application thingy for the web portion of the meeting, and it will prompt 
> you for a phone number to call you to join the audio portion of the 
> meeting.  Mike will be transmitting his slides on the web portion (just 
> because we can / it's fun ;-) ).
>
>
> On Apr 22, 2009, at 8:39 AM, Mike Dubman wrote:
>
>> Hello guys,
>>
>> Here is a small ppt with MTToGDS summary for tomorrow`s meeting.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 5:02 PM, Jeff Squyres  wrote:
>> Will there be dancing bears on the slides?  I'll only accept slides with 
>> dancing bears!
>>
>> ;-)
>>
>> (no need to be formal; if slides help, great, otherwise don't make slides 
>> just because we have webex available)
>>
>>
>>
>> On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:
>>
>> I will prepare ppt with summary of what were discussed and agreed, 
>> milestones, open questions and other thoughts.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres  wrote:
>> Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next 
>> Thuesday, April 23.
>>
>> I'll send the webex invites in a separate email.  Mike: if you have slides 
>> or other electronic material to show during the call, we can use webex for 
>> that.  Otherwise, we can just use the telephone part of webex and ignore 
>> the web part.
>>
>>
>>
>> On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:
>>
>> I have been listening in on the thread, but have not had time to
>> really look at much (which is why I have not been replying). I'm
>> interested in listening in on the teleconf as well, though if I become
>> a blocker for finding a time feel free to cut me out.
>>
>> Best,
>> Josh
>>
>> On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:
>>
>> >> BTW -- if it's useful to have a teleconference about this kind of
>> >> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> >> the world, including Israel...
>> >>
>> >>
>> >> sure, what about next week?
>> >
>> > I have a Doodle account -- let's try that to do the scheduling:
>> >
>> >http://doodle.com/gzpgaun2ef4szt29
>> >
>> > Ethan, Josh, and I are all in US Eastern timezone (I don't know if
>> > Josh will participate), so that might make scheduling *slightly*
>> > easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
>> > Eastern -- that's already pretty late in Israel.  I also didn't list
>> > Friday, since that's the weekend in Israel.
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Jeff Squyres]

The slides will also be on webex on the call tomorrow.  Use the URL to  
join the meeting in the email invite that you got.  That URL will  
launch an application thingy for the web portion of the meeting, and  
it will prompt you for a phone number to call you to join the audio  
portion of the meeting.  Mike will be transmitting his slides on the  
web portion (just because we can / it's fun ;-) ).



On Apr 22, 2009, at 8:39 AM, Mike Dubman wrote:


Hello guys,

Here is a small ppt with MTToGDS summary for tomorrow`s meeting.
regards

Mike

On Thu, Apr 16, 2009 at 5:02 PM, Jeff Squyres   
wrote:
Will there be dancing bears on the slides?  I'll only accept slides  
with dancing bears!


;-)

(no need to be formal; if slides help, great, otherwise don't make  
slides just because we have webex available)




On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:

I will prepare ppt with summary of what were discussed and agreed,  
milestones, open questions and other thoughts.

regards

Mike

On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres   
wrote:
Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next  
Thuesday, April 23.


I'll send the webex invites in a separate email.  Mike: if you have  
slides or other electronic material to show during the call, we can  
use webex for that.  Otherwise, we can just use the telephone part  
of webex and ignore the web part.




On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:

I have been listening in on the thread, but have not had time to
really look at much (which is why I have not been replying). I'm
interested in listening in on the teleconf as well, though if I become
a blocker for finding a time feel free to cut me out.

Best,
Josh

On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:

>> BTW -- if it's useful to have a teleconference about this kind of
>> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> the world, including Israel...
>>
>>
>> sure, what about next week?
>
> I have a Doodle account -- let's try that to do the scheduling:
>
>http://doodle.com/gzpgaun2ef4szt29
>
> Ethan, Josh, and I are all in US Eastern timezone (I don't know if
> Josh will participate), so that might make scheduling *slightly*
> easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
> Eastern -- that's already pretty late in Israel.  I also didn't list
> Friday, since that's the weekend in Israel.

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

Hello guys,

Here is a small ppt with MTToGDS summary for tomorrow`s meeting.
regards

Mike

On Thu, Apr 16, 2009 at 5:02 PM, Jeff Squyres  wrote:

> Will there be dancing bears on the slides?  I'll only accept slides with
> dancing bears!
>
> ;-)
>
> (no need to be formal; if slides help, great, otherwise don't make slides
> just because we have webex available)
>
>
>
> On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:
>
>  I will prepare ppt with summary of what were discussed and agreed,
>> milestones, open questions and other thoughts.
>> regards
>>
>> Mike
>>
>> On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres  wrote:
>> Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next
>> Thuesday, April 23.
>>
>> I'll send the webex invites in a separate email.  Mike: if you have slides
>> or other electronic material to show during the call, we can use webex for
>> that.  Otherwise, we can just use the telephone part of webex and ignore the
>> web part.
>>
>>
>>
>> On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:
>>
>> I have been listening in on the thread, but have not had time to
>> really look at much (which is why I have not been replying). I'm
>> interested in listening in on the teleconf as well, though if I become
>> a blocker for finding a time feel free to cut me out.
>>
>> Best,
>> Josh
>>
>> On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:
>>
>> >> BTW -- if it's useful to have a teleconference about this kind of
>> >> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> >> the world, including Israel...
>> >>
>> >>
>> >> sure, what about next week?
>> >
>> > I have a Doodle account -- let's try that to do the scheduling:
>> >
>> >http://doodle.com/gzpgaun2ef4szt29
>> >
>> > Ethan, Josh, and I are all in US Eastern timezone (I don't know if
>> > Josh will participate), so that might make scheduling *slightly*
>> > easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
>> > Eastern -- that's already pretty late in Israel.  I also didn't list
>> > Friday, since that's the weekend in Israel.
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>


MTToGDS.ppt
Description: MS-Powerpoint presentation

Re: [MTT devel] GSOC application

[Jeff Squyres]

Will there be dancing bears on the slides?  I'll only accept slides  
with dancing bears!


;-)

(no need to be formal; if slides help, great, otherwise don't make  
slides just because we have webex available)



On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote:

I will prepare ppt with summary of what were discussed and agreed,  
milestones, open questions and other thoughts.

regards

Mike

On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres   
wrote:
Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next  
Thuesday, April 23.


I'll send the webex invites in a separate email.  Mike: if you have  
slides or other electronic material to show during the call, we can  
use webex for that.  Otherwise, we can just use the telephone part  
of webex and ignore the web part.




On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:

I have been listening in on the thread, but have not had time to
really look at much (which is why I have not been replying). I'm
interested in listening in on the teleconf as well, though if I become
a blocker for finding a time feel free to cut me out.

Best,
Josh

On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:

>> BTW -- if it's useful to have a teleconference about this kind of
>> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> the world, including Israel...
>>
>>
>> sure, what about next week?
>
> I have a Doodle account -- let's try that to do the scheduling:
>
>http://doodle.com/gzpgaun2ef4szt29
>
> Ethan, Josh, and I are all in US Eastern timezone (I don't know if
> Josh will participate), so that might make scheduling *slightly*
> easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
> Eastern -- that's already pretty late in Israel.  I also didn't list
> Friday, since that's the weekend in Israel.

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

I will prepare ppt with summary of what were discussed and agreed,
milestones, open questions and other thoughts.
regards

Mike

On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres  wrote:

> Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next
> Thuesday, April 23.
>
> I'll send the webex invites in a separate email.  Mike: if you have slides
> or other electronic material to show during the call, we can use webex for
> that.  Otherwise, we can just use the telephone part of webex and ignore the
> web part.
>
>
>
> On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:
>
>  I have been listening in on the thread, but have not had time to
>> really look at much (which is why I have not been replying). I'm
>> interested in listening in on the teleconf as well, though if I become
>> a blocker for finding a time feel free to cut me out.
>>
>> Best,
>> Josh
>>
>> On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:
>>
>> >> BTW -- if it's useful to have a teleconference about this kind of
>> >> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> >> the world, including Israel...
>> >>
>> >>
>> >> sure, what about next week?
>> >
>> > I have a Doodle account -- let's try that to do the scheduling:
>> >
>> >http://doodle.com/gzpgaun2ef4szt29
>> >
>> > Ethan, Josh, and I are all in US Eastern timezone (I don't know if
>> > Josh will participate), so that might make scheduling *slightly*
>> > easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
>> > Eastern -- that's already pretty late in Israel.  I also didn't list
>> > Friday, since that's the weekend in Israel.
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>

Re: [MTT devel] GSOC application

[Jeff Squyres]

Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next  
Thuesday, April 23.


I'll send the webex invites in a separate email.  Mike: if you have  
slides or other electronic material to show during the call, we can  
use webex for that.  Otherwise, we can just use the telephone part of  
webex and ignore the web part.



On Apr 15, 2009, at 4:18 PM, Josh Hursey wrote:


I have been listening in on the thread, but have not had time to
really look at much (which is why I have not been replying). I'm
interested in listening in on the teleconf as well, though if I become
a blocker for finding a time feel free to cut me out.

Best,
Josh

On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:

>> BTW -- if it's useful to have a teleconference about this kind of
>> stuff, I can host a WebEx meeting.  WebEx has local dialins around
>> the world, including Israel...
>>
>>
>> sure, what about next week?
>
> I have a Doodle account -- let's try that to do the scheduling:
>
>http://doodle.com/gzpgaun2ef4szt29
>
> Ethan, Josh, and I are all in US Eastern timezone (I don't know if
> Josh will participate), so that might make scheduling *slightly*
> easier.  I started timeslots at 8am US Eastern and stopped as 2pm US
> Eastern -- that's already pretty late in Israel.  I also didn't list
> Friday, since that's the weekend in Israel.

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Josh Hursey]

I have been listening in on the thread, but have not had time to  
really look at much (which is why I have not been replying). I'm  
interested in listening in on the teleconf as well, though if I become  
a blocker for finding a time feel free to cut me out.


Best,
Josh

On Apr 14, 2009, at 8:51 PM, Jeff Squyres wrote:

BTW -- if it's useful to have a teleconference about this kind of  
stuff, I can host a WebEx meeting.  WebEx has local dialins around  
the world, including Israel...



sure, what about next week?


I have a Doodle account -- let's try that to do the scheduling:

   http://doodle.com/gzpgaun2ef4szt29

Ethan, Josh, and I are all in US Eastern timezone (I don't know if  
Josh will participate), so that might make scheduling *slightly*  
easier.  I started timeslots at 8am US Eastern and stopped as 2pm US  
Eastern -- that's already pretty late in Israel.  I also didn't list  
Friday, since that's the weekend in Israel.

Re: [MTT devel] GSOC application

[Mike Dubman]

On Wed, Apr 15, 2009 at 8:50 PM, Jeff Squyres  wrote:

> On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote:
>
>  yep. correct. We can define only static attributes (which we know for sure
>> should present in every object of given type and leave phase specific
>> attributes to stay dynamic)
>>
>> Hmm.  I would think that even in each phase, we have a bunch of fields
>> that we *know* we want to have, right?
>>
>> correct, in gds terms they call it static attributes.
>>
>
> I was more nit-picking your statement that we would only have a field
> fields that would be available for every phase, and then use dynamic fields
> for all phase-specific data.  While GDS *can* handle that, wouldn't it be
> better to have a model for each phase (similar to your mockup) that expects
> a specific set of data for each phase?  Extra data on top of that would be a
> bonus, but wouldn't be necessary.  More specifically: we *know* what data
> should be available in each phase, so why not tell GDS about it in the model
> (rather than using dynamic fields that we know will always be there)?
>
> Perhaps we're just getting confused by language and I should wait for your
> next mock-up to see what you guys do... :-)
>

completely agree, the model for every phase object should contain mostly
static fields, based on current mtt phases info.
Also, we will have flexibility to expand phase objects without changing the
model.

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote:

yep. correct. We can define only static attributes (which we know  
for sure should present in every object of given type and leave  
phase specific attributes to stay dynamic)


Hmm.  I would think that even in each phase, we have a bunch of  
fields that we *know* we want to have, right?


correct, in gds terms they call it static attributes.


I was more nit-picking your statement that we would only have a field  
fields that would be available for every phase, and then use dynamic  
fields for all phase-specific data.  While GDS *can* handle that,  
wouldn't it be better to have a model for each phase (similar to your  
mockup) that expects a specific set of data for each phase?  Extra  
data on top of that would be a bonus, but wouldn't be necessary.  More  
specifically: we *know* what data should be available in each phase,  
so why not tell GDS about it in the model (rather than using dynamic  
fields that we know will always be there)?


Perhaps we're just getting confused by language and I should wait for  
your next mock-up to see what you guys do... :-)



I have a Doodle account -- let's try that to do the scheduling:

  http://doodle.com/gzpgaun2ef4szt29

aha, tried and here what I got:



Ahh -- looks like they're offline for the next ~2 hours (3pm US  
Pacific / 21:00 CET).  Well, we can't complain -- it's a free  
service.  :-)


--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

On Wed, Apr 15, 2009 at 5:23 PM, Jeff Squyres  wrote:

> On Apr 15, 2009, at 9:14 AM, Mike Dubman wrote:
>
>  Hmm.  Ok, so you're saying that we define a "phase object" (for each
>> phase) with all the fields that we expect to have, but if we need to, we can
>> create fields on the fly, and google will just "do the right thing" and
>> associate *all* the data (the "expected" fields and the "dynamic" fields)
>> together?
>>
>> yep. correct. We can define only static attributes (which we know for sure
>> should present in every object of given type and leave phase specific
>> attributes to stay dynamic)
>>
>
> Hmm.  I would think that even in each phase, we have a bunch of fields that
> we *know* we want to have, right?


correct, in gds terms they call it static attributes.


>
>
>  I have a Doodle account -- let's try that to do the scheduling:
>>
>>   http://doodle.com/gzpgaun2ef4szt29
>>
>> Ethan, Josh, and I are all in US Eastern timezone (I don't know if Josh
>> will participate), so that might make scheduling *slightly* easier.  I
>> started timeslots at 8am US Eastern and stopped as 2pm US Eastern -- that's
>> already pretty late in Israel.  I also didn't list Friday, since that's the
>> weekend in Israel.
>>
>> can we do it on your morining? (our after noon) :)
>>
>
>
> Visit the Doodle URL (above) and you'll see.  :-)


aha, tried and here what I got:

Wir sind bald zurück
i tempt to agree with it :)





>
>
> --
> Jeff Squyres
> Cisco Systems
>
>

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Apr 15, 2009, at 9:14 AM, Mike Dubman wrote:

Hmm.  Ok, so you're saying that we define a "phase object" (for each  
phase) with all the fields that we expect to have, but if we need  
to, we can create fields on the fly, and google will just "do the  
right thing" and associate *all* the data (the "expected" fields and  
the "dynamic" fields) together?


yep. correct. We can define only static attributes (which we know  
for sure should present in every object of given type and leave  
phase specific attributes to stay dynamic)


Hmm.  I would think that even in each phase, we have a bunch of fields  
that we *know* we want to have, right?



I have a Doodle account -- let's try that to do the scheduling:

   http://doodle.com/gzpgaun2ef4szt29

Ethan, Josh, and I are all in US Eastern timezone (I don't know if  
Josh will participate), so that might make scheduling *slightly*  
easier.  I started timeslots at 8am US Eastern and stopped as 2pm US  
Eastern -- that's already pretty late in Israel.  I also didn't list  
Friday, since that's the weekend in Israel.


can we do it on your morining? (our after noon) :)



Visit the Doodle URL (above) and you'll see.  :-)

--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

On Wed, Apr 15, 2009 at 3:51 AM, Jeff Squyres  wrote:

> On Apr 14, 2009, at 2:27 PM, Mike Dubman wrote:
>
> Ah, good point (python/java not perl).  But I think that
>> lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we have
>> invested a lot of time/effort into getting our particular mtt clients setup
>> just the way we want them, setting up INI files, submitting to batch
>> schedulers, etc.
>>
>> A GoogleDataStore.pm reporter could well fork/exec a python/java
>> executable to do the actual communication/storing of the data, right...?
>>  More below.
>>
>> completely agree, once we have external python/java/cobol scripts to
>> manipulate GDS objects, we should wrap it by perl and call from MTT in same
>> way like it works today for submitting to the postgress.
>>
>
> So say we all!  :-)
>
> (did they show Battlestar Gallactica in Israel?  :-) )
>
> sounds good, we should introduce some guid (like pid) for mtt session,
>> where all mtt results generated by this session will be referring to this
>> guid.  Later we use this guid to submit partial results as they become ready
>> and connect it to the appropriate mtt session object (see models.py)
>>
>
> I *believe* have have 2 values like this in the MTT client already:
>
> - an ID that represents a single MTT client run
> - an ID that represents a single MTT mpi install->test build->test run tree
>
>
> I think that Ethan was asking was: can't MTT run Fluent and then use the
>> normal Reporter mechanism to report the results into whatever back-end data
>> store we have?  (postgres or GDS)
>>
>> ahhh, okie, i see.
>>
>> Correct me if Im wrong, the current mtt implementation allows following
>> way of executing mpi test:
>> /path/to/mpirun  
>>
>
> Yes and no; it's controlled by the mpi details section, right?  You can put
> whatever you want in there.
>
> Many mpi based applications have embedded MPI libraries and non-standard
>> way to start it, one should set env variable to point to desired mpi
>> installation or pass it as cmd line argument, for example:
>>
>> for fluent:
>>
>> export OPENMPI_ROOT=/path/to/openmpi
>> fluent 
>>
>>
>> for pamcrash:
>> pamworld -np 2 -mpidir=/path/to/openmpi/dir 
>>
>> Im not sure if it is possible to express that execution semantic in mtt
>> ini file. Please suggest.
>> So far, it seems that such executions can be handled externally from mtt
>> but using same object model.
>>
>
> Understood.  I think you *could* get MTT to run these with specialized mpi
> details sections.  But it may or may not be worth it.
>
> For the attachment...
>>
>> I can "sorta read" python, but I'm not familiar with its intricacies and
>> its internal APIs.
>>
>> - models.py: looks good.  I don't know if *all* the fields we have are
>> listed here; it looks fairly short to me.  Did you attempt to include all of
>> the fields we submit through the various phases in Reporter are there, or
>> did you intentionally leave some out?  (I honestly haven't checked; it just
>> "feels short" to me compared to our SQL schema).
>>
>> I listed only some of the fields in every object representing specific
>> test result source (called phase in mtt language).
>>
>
> Ok.  So that's only a sample -- just showing an example, not necessarily
> trying to be complete.  Per Ethan's comments, there are a bunch of other
> fields that we have and/or we might just be able to "tie them together" in
> GDS.  I.e., our data is hierarchical -- it worked well enough in SQL because
> you could just have one record about a test build refer to another record
> about the corresponding mpi install.  And so on.  Can we do something
> similar in GDS?
>


yep, actually in GDS it should be much easier to have hierarchy, because it
is OO storage. We just need to map all object relations and put it in
models.py - gds will do the rest :)




>
>
> This is because every test result source object is derived from python
>> provided db.Expando class. This gives us great flexibility, like adding
>> dynamic attributes for every objects, for example:
>>
>> obj = new MttBuildPhaseResult()
>> obj.my_favorite_dynamic_key = "hello"
>> obj.my_another_dynamic_key = 7
>>
>> So, we can have all phase attributes in the phase object without defining
>> it in the *sql schema way*. Also we can query object model by these dynamic
>> keys.
>>
>
> Hmm.  Ok, so you're saying that we define a "phase object" (for each phase)
> with all the fields that we expect to have, but if we need to, we can create
> fields on the fly, and google will just "do the right thing" and associate
> *all* the data (the "expected" fields and the "dynamic" fields) together?


yep. correct. We can define only static attributes (which we know for sure
should present in every object of given type and leave phase specific
attributes to stay dynamic)


>
>
> --> meta question: is it in the zen of GDS to not have too many index
>> fields like you would in SQL?  I.e., if you want to do an operation on GDS
>> that you
>>
>

Re: [MTT devel] GSOC application

[Mike Dubman]

On Tue, Apr 14, 2009 at 11:50 PM, Ethan Mallove wrote:

>  On Tue, Apr/14/2009 09:27:14PM, Mike Dubman wrote:
> >On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres 
> wrote:
> >
> >  On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:
> >
> >Hello Ethan,
> >
> >  Sorry for joining the discussion late... I was on travel last week
> and
> >  that always makes me waaay behind on my INBOX. *:-(
> >
> >On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove <
> ethan.mall...@sun.com>
> >wrote:
> >
> >Will this translate to something like
> >lib/MTT/Reporter/GoogleDatabase.pm? *If we are to move away from
> the
> >current MTT Postgres database, we want to be able to submit
> results to
> >both the current MTT database and the new Google database during
> the
> >transition period. Having a GoogleDatabase.pm would make this
> easier.
> >
> >I think we should keep both storage options: current postgress and
> >datastore. The mtt changes will be minor to support datastore.
> >Due that fact that google appengine API (as well as datastore API)
> can
> >be python or java only, we will create external scripts to
> manipulate
> >datastore objects:
> >
> >  Ah, good point (python/java not perl). *But I think that
> >  lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing --
> we
> >  have invested a lot of time/effort into getting our particular mtt
> >  clients setup just the way we want them, setting up INI files,
> >  submitting to batch schedulers, etc.
> >
> >  A GoogleDataStore.pm reporter could well fork/exec a python/java
> >  executable to do the actual communication/storing of the data,
> right...?
> >  *More below.
> >
> >completely agree, once we have external python/java/cobol scripts to
> >manipulate GDS objects, we should wrap it by perl and call from MTT in
> >same way like it works today for submitting to the postgress.
> >
> >*
> >
> >The mtt will dump test results in xml format. Then, we provide two
> >python (or java?) scripts:
> >
> >mtt-results-submit-to-datastore.py - script will be called at the
> end
> >of mtt run and will read xml files, create objects and save to
> >datastore
> >
> >  Could be pretty easy to have a Reporter/GDS.pm (I keep making that
> >  filename shorter, don't I? :-) ) that simply invokes the
> >  mtt-result-submit-to-datastore.pt script on the xml that it dumped
> for
> >  that particular test.
> >
> >  Specifically: I do like having partial results submitted while my
> MTT
> >  tests are running. *Cisco's testing cycle is about 24 hours, but
> groups
> >  of tests are finishing all the time, so it's good to see those
> results
> >  without having to wait the full 24 hours before anything shows up.
> *I
> >  guess that's my only comment on the idea of having a script that
> >  traverses the MTT scratch to find / submit everything -- I'd prefer
> if
> >  we kept the same Reporter idea and used an underlying .py script to
> >  submit results as they become ready.
> >
> >  Is this do-able?
> >
> >sounds good, we should introduce some guid (like pid) for mtt session,
> >where all mtt results generated by this session will be referring to
> this
> >guid.* Later we use this guid to submit partial results as they become
> >ready and connect it to the appropriate mtt session object (see
> models.py)
> >
> >mtt-results-query.py - sample script to query datastore and
> generate
> >some simple visual/tabular reports. It will serve as tutorial for
> >howto access mtt data from scripts for reporting.
> >
> >Later, we add another script to replace php web frontend. It will
> be
> >hosted on google appengine machines and will provide web viewer
> for
> >mtt results. (same way like index.php does today)
> >
> >  Sounds good.
> >
> >> * * *b. mtt_save_to_db.py - script which will go over mtt
> scratch
> >dir, find
> >> * * *all xml files generated for every mtt phase, parse it and
> save
> >to
> >> * * *datastore, preserving test results relations,i.e. all test
> >results will
> >> * * *be grouped by mtt general info: mpi version, name, date,
> 
> >>
> >> * * *c. same script can scan, parse and save from xml files
> >generated by
> >> * * *wrapper scripts for non mtt based executions (fluent, ..)
> >
> >I'm confused here. *Can't MTT be outfitted to report results of a
> >Fluent run?
> >
> >I think we can enhance mtt to be not only mpi testing platform,
> but
> >also to serve as mpi benchmarking platform. We can use datastore
> to
> >keep mpi-based benchmarking results in the same manner like mtt
> does
> >for testing results. (no changes to 

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Apr 14, 2009, at 2:27 PM, Mike Dubman wrote:

Ah, good point (python/java not perl).  But I think that lib/MTT/ 
Reporter/GoogleDataStore.pm could still be a good thing -- we have  
invested a lot of time/effort into getting our particular mtt  
clients setup just the way we want them, setting up INI files,  
submitting to batch schedulers, etc.


A GoogleDataStore.pm reporter could well fork/exec a python/java  
executable to do the actual communication/storing of the data,  
right...?  More below.


completely agree, once we have external python/java/cobol scripts to  
manipulate GDS objects, we should wrap it by perl and call from MTT  
in same way like it works today for submitting to the postgress.


So say we all!  :-)

(did they show Battlestar Gallactica in Israel?  :-) )

sounds good, we should introduce some guid (like pid) for mtt  
session, where all mtt results generated by this session will be  
referring to this guid.  Later we use this guid to submit partial  
results as they become ready and connect it to the appropriate mtt  
session object (see models.py)


I *believe* have have 2 values like this in the MTT client already:

- an ID that represents a single MTT client run
- an ID that represents a single MTT mpi install->test build->test run  
tree


I think that Ethan was asking was: can't MTT run Fluent and then use  
the normal Reporter mechanism to report the results into whatever  
back-end data store we have?  (postgres or GDS)


ahhh, okie, i see.

Correct me if Im wrong, the current mtt implementation allows  
following way of executing mpi test:

/path/to/mpirun  


Yes and no; it's controlled by the mpi details section, right?  You  
can put whatever you want in there.


Many mpi based applications have embedded MPI libraries and non- 
standard way to start it, one should set env variable to point to  
desired mpi installation or pass it as cmd line argument, for example:


for fluent:

export OPENMPI_ROOT=/path/to/openmpi
fluent 


for pamcrash:
pamworld -np 2 -mpidir=/path/to/openmpi/dir 

Im not sure if it is possible to express that execution semantic in  
mtt ini file. Please suggest.
So far, it seems that such executions can be handled externally from  
mtt but using same object model.


Understood.  I think you *could* get MTT to run these with specialized  
mpi details sections.  But it may or may not be worth it.



For the attachment...

I can "sorta read" python, but I'm not familiar with its intricacies  
and its internal APIs.


- models.py: looks good.  I don't know if *all* the fields we have  
are listed here; it looks fairly short to me.  Did you attempt to  
include all of the fields we submit through the various phases in  
Reporter are there, or did you intentionally leave some out?  (I  
honestly haven't checked; it just "feels short" to me compared to  
our SQL schema).


I listed only some of the fields in every object representing  
specific test result source (called phase in mtt language).


Ok.  So that's only a sample -- just showing an example, not  
necessarily trying to be complete.  Per Ethan's comments, there are a  
bunch of other fields that we have and/or we might just be able to  
"tie them together" in GDS.  I.e., our data is hierarchical -- it  
worked well enough in SQL because you could just have one record about  
a test build refer to another record about the corresponding mpi  
install.  And so on.  Can we do something similar in GDS?


This is because every test result source object is derived from  
python provided db.Expando class. This gives us great flexibility,  
like adding dynamic attributes for every objects, for example:


obj = new MttBuildPhaseResult()
obj.my_favorite_dynamic_key = "hello"
obj.my_another_dynamic_key = 7

So, we can have all phase attributes in the phase object without  
defining it in the *sql schema way*. Also we can query object model  
by these dynamic keys.


Hmm.  Ok, so you're saying that we define a "phase object" (for each  
phase) with all the fields that we expect to have, but if we need to,  
we can create fields on the fly, and google will just "do the right  
thing" and associate *all* the data (the "expected" fields and the  
"dynamic" fields) together?


--> meta question: is it in the zen of GDS to not have too many  
index fields like you would in SQL?  I.e., if you want to do an  
operation on GDS that you


as far as it seems now, gds creates indexes automatically and also  
provides API to define indexes manually.
would typically use an SQL index field for, is the idea that you  
would do a map/reduce to select the data instead of an index field?


yep. seems correct.


K.

- start_datastore.sh: hmm.  This script seems to imply that the  
datastore is *local*!  Don't we have to HTTP submit the results to  
Google?  More specifically: what is dev_appserver.py?  Is that,  
perchance, just a local proxy agent that will end up submitting our  
data to $datastore_path, which actually

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Tue, Apr/14/2009 09:27:14PM, Mike Dubman wrote:
>On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres  wrote:
> 
>  On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:
> 
>Hello Ethan,
> 
>  Sorry for joining the discussion late... I was on travel last week and
>  that always makes me waaay behind on my INBOX. *:-(
> 
>On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove 
>wrote:
> 
>Will this translate to something like
>lib/MTT/Reporter/GoogleDatabase.pm? *If we are to move away from the
>current MTT Postgres database, we want to be able to submit results to
>both the current MTT database and the new Google database during the
>transition period. Having a GoogleDatabase.pm would make this easier.
> 
>I think we should keep both storage options: current postgress and
>datastore. The mtt changes will be minor to support datastore.
>Due that fact that google appengine API (as well as datastore API) can
>be python or java only, we will create external scripts to manipulate
>datastore objects:
> 
>  Ah, good point (python/java not perl). *But I think that
>  lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we
>  have invested a lot of time/effort into getting our particular mtt
>  clients setup just the way we want them, setting up INI files,
>  submitting to batch schedulers, etc.
> 
>  A GoogleDataStore.pm reporter could well fork/exec a python/java
>  executable to do the actual communication/storing of the data, right...?
>  *More below.
> 
>completely agree, once we have external python/java/cobol scripts to
>manipulate GDS objects, we should wrap it by perl and call from MTT in
>same way like it works today for submitting to the postgress.
> 
>*
> 
>The mtt will dump test results in xml format. Then, we provide two
>python (or java?) scripts:
> 
>mtt-results-submit-to-datastore.py - script will be called at the end
>of mtt run and will read xml files, create objects and save to
>datastore
> 
>  Could be pretty easy to have a Reporter/GDS.pm (I keep making that
>  filename shorter, don't I? :-) ) that simply invokes the
>  mtt-result-submit-to-datastore.pt script on the xml that it dumped for
>  that particular test.
> 
>  Specifically: I do like having partial results submitted while my MTT
>  tests are running. *Cisco's testing cycle is about 24 hours, but groups
>  of tests are finishing all the time, so it's good to see those results
>  without having to wait the full 24 hours before anything shows up. *I
>  guess that's my only comment on the idea of having a script that
>  traverses the MTT scratch to find / submit everything -- I'd prefer if
>  we kept the same Reporter idea and used an underlying .py script to
>  submit results as they become ready.
> 
>  Is this do-able?
> 
>sounds good, we should introduce some guid (like pid) for mtt session,
>where all mtt results generated by this session will be referring to this
>guid.* Later we use this guid to submit partial results as they become
>ready and connect it to the appropriate mtt session object (see models.py)
> 
>mtt-results-query.py - sample script to query datastore and generate
>some simple visual/tabular reports. It will serve as tutorial for
>howto access mtt data from scripts for reporting.
> 
>Later, we add another script to replace php web frontend. It will be
>hosted on google appengine machines and will provide web viewer for
>mtt results. (same way like index.php does today)
> 
>  Sounds good.
> 
>> * * *b. mtt_save_to_db.py - script which will go over mtt scratch
>dir, find
>> * * *all xml files generated for every mtt phase, parse it and save
>to
>> * * *datastore, preserving test results relations,i.e. all test
>results will
>> * * *be grouped by mtt general info: mpi version, name, date, 
>>
>> * * *c. same script can scan, parse and save from xml files
>generated by
>> * * *wrapper scripts for non mtt based executions (fluent, ..)
> 
>I'm confused here. *Can't MTT be outfitted to report results of a
>Fluent run?
> 
>I think we can enhance mtt to be not only mpi testing platform, but
>also to serve as mpi benchmarking platform. We can use datastore to
>keep mpi-based benchmarking results in the same manner like mtt does
>for testing results. (no changes to mtt required for that, it is just
>a side effect of using datastore to keep data of any type)
> 
>  I think that Ethan was asking was: can't MTT run Fluent and then use the
>  normal Reporter mechanism to report the results into whatever back-end
>  data store we have? *(postgres or GDS)
> 
>

Re: [MTT devel] GSOC application

[Mike Dubman]

On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres  wrote:

> On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:
>
>  Hello Ethan,
>>
>
> Sorry for joining the discussion late... I was on travel last week and that
> always makes me waaay behind on my INBOX.  :-(
>
>  On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove 
>> wrote:
>>
>> Will this translate to something like
>> lib/MTT/Reporter/GoogleDatabase.pm?  If we are to move away from the
>> current MTT Postgres database, we want to be able to submit results to
>> both the current MTT database and the new Google database during the
>> transition period. Having a GoogleDatabase.pm would make this easier.
>>
>> I think we should keep both storage options: current postgress and
>> datastore. The mtt changes will be minor to support datastore.
>> Due that fact that google appengine API (as well as datastore API) can be
>> python or java only, we will create external scripts to manipulate datastore
>> objects:
>>
>
> Ah, good point (python/java not perl).  But I think that
> lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we have
> invested a lot of time/effort into getting our particular mtt clients setup
> just the way we want them, setting up INI files, submitting to batch
> schedulers, etc.
>
> A GoogleDataStore.pm reporter could well fork/exec a python/java executable
> to do the actual communication/storing of the data, right...?  More below.
>

completely agree, once we have external python/java/cobol scripts to
manipulate GDS objects, we should wrap it by perl and call from MTT in same
way like it works today for submitting to the postgress.



>
>
>  The mtt will dump test results in xml format. Then, we provide two python
>> (or java?) scripts:
>>
>> mtt-results-submit-to-datastore.py - script will be called at the end of
>> mtt run and will read xml files, create objects and save to datastore
>>
>
> Could be pretty easy to have a Reporter/GDS.pm (I keep making that filename
> shorter, don't I? :-) ) that simply invokes the mtt-result-
> submit-to-datastore.pt script on the xml that it dumped for that
> particular test.
>
> Specifically: I do like having partial results submitted while my MTT tests
> are running.  Cisco's testing cycle is about 24 hours, but groups of tests
> are finishing all the time, so it's good to see those results without having
> to wait the full 24 hours before anything shows up.  I guess that's my only
> comment on the idea of having a script that traverses the MTT scratch to
> find / submit everything -- I'd prefer if we kept the same Reporter idea and
> used an underlying .py script to submit results as they become ready.
>
> Is this do-able?


sounds good, we should introduce some guid (like pid) for mtt session, where
all mtt results generated by this session will be referring to this guid.
Later we use this guid to submit partial results as they become ready and
connect it to the appropriate mtt session object (see models.py)


>
>  mtt-results-query.py - sample script to query datastore and generate some
>> simple visual/tabular reports. It will serve as tutorial for howto access
>> mtt data from scripts for reporting.
>>
>> Later, we add another script to replace php web frontend. It will be
>> hosted on google appengine machines and will provide web viewer for mtt
>> results. (same way like index.php does today)
>>
>
> Sounds good.
>
>  >  b. mtt_save_to_db.py - script which will go over mtt scratch dir,
>> find
>> >  all xml files generated for every mtt phase, parse it and save to
>> >  datastore, preserving test results relations,i.e. all test results
>> will
>> >  be grouped by mtt general info: mpi version, name, date, 
>> >
>> >  c. same script can scan, parse and save from xml files generated by
>> >  wrapper scripts for non mtt based executions (fluent, ..)
>>
>> I'm confused here.  Can't MTT be outfitted to report results of a
>> Fluent run?
>>
>>
>> I think we can enhance mtt to be not only mpi testing platform, but also
>> to serve as mpi benchmarking platform. We can use datastore to keep
>> mpi-based benchmarking results in the same manner like mtt does for testing
>> results. (no changes to mtt required for that, it is just a side effect of
>> using datastore to keep data of any type)
>>
>
> I think that Ethan was asking was: can't MTT run Fluent and then use the
> normal Reporter mechanism to report the results into whatever back-end data
> store we have?  (postgres or GDS)
>


ahhh, okie, i see.

Correct me if Im wrong, the current mtt implementation allows following way
of executing mpi test:
/path/to/mpirun  

Many mpi based applications have embedded MPI libraries and non-standard way
to start it, one should set env variable to point to desired mpi
installation or pass it as cmd line argument, for example:

for fluent:

export OPENMPI_ROOT=/path/to/openmpi
fluent 


for pamcrash:
pamworld -np 2 -mpidir=/path/to/openmpi/dir 

Im not sure if it is possible to 

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote:


Hello Ethan,


Sorry for joining the discussion late... I was on travel last week and  
that always makes me waaay behind on my INBOX.  :-(


On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove  
 wrote:


Will this translate to something like
lib/MTT/Reporter/GoogleDatabase.pm?  If we are to move away from the
current MTT Postgres database, we want to be able to submit results to
both the current MTT database and the new Google database during the
transition period. Having a GoogleDatabase.pm would make this easier.

I think we should keep both storage options: current postgress and  
datastore. The mtt changes will be minor to support datastore.
Due that fact that google appengine API (as well as datastore API)  
can be python or java only, we will create external scripts to  
manipulate datastore objects:


Ah, good point (python/java not perl).  But I think that lib/MTT/ 
Reporter/GoogleDataStore.pm could still be a good thing -- we have  
invested a lot of time/effort into getting our particular mtt clients  
setup just the way we want them, setting up INI files, submitting to  
batch schedulers, etc.


A GoogleDataStore.pm reporter could well fork/exec a python/java  
executable to do the actual communication/storing of the data,  
right...?  More below.


The mtt will dump test results in xml format. Then, we provide two  
python (or java?) scripts:


mtt-results-submit-to-datastore.py - script will be called at the  
end of mtt run and will read xml files, create objects and save to  
datastore


Could be pretty easy to have a Reporter/GDS.pm (I keep making that  
filename shorter, don't I? :-) ) that simply invokes the mtt-result- 
submit-to-datastore.pt script on the xml that it dumped for that  
particular test.


Specifically: I do like having partial results submitted while my MTT  
tests are running.  Cisco's testing cycle is about 24 hours, but  
groups of tests are finishing all the time, so it's good to see those  
results without having to wait the full 24 hours before anything shows  
up.  I guess that's my only comment on the idea of having a script  
that traverses the MTT scratch to find / submit everything -- I'd  
prefer if we kept the same Reporter idea and used an underlying .py  
script to submit results as they become ready.


Is this do-able?

mtt-results-query.py - sample script to query datastore and generate  
some simple visual/tabular reports. It will serve as tutorial for  
howto access mtt data from scripts for reporting.


Later, we add another script to replace php web frontend. It will be  
hosted on google appengine machines and will provide web viewer for  
mtt results. (same way like index.php does today)


Sounds good.

>  b. mtt_save_to_db.py - script which will go over mtt scratch  
dir, find
>  all xml files generated for every mtt phase, parse it and  
save to
>  datastore, preserving test results relations,i.e. all test  
results will

>  be grouped by mtt general info: mpi version, name, date, 
>
>  c. same script can scan, parse and save from xml files  
generated by

>  wrapper scripts for non mtt based executions (fluent, ..)

I'm confused here.  Can't MTT be outfitted to report results of a
Fluent run?


I think we can enhance mtt to be not only mpi testing platform, but  
also to serve as mpi benchmarking platform. We can use datastore to  
keep mpi-based benchmarking results in the same manner like mtt does  
for testing results. (no changes to mtt required for that, it is  
just a side effect of using datastore to keep data of any type)


I think that Ethan was asking was: can't MTT run Fluent and then use  
the normal Reporter mechanism to report the results into whatever back- 
end data store we have?  (postgres or GDS)


I can see the value of both sides -- a) using the MTT client as the  
gateway to *all* data storage, or b) making MTT but one (possibly of  
many) tools that can write into the GDS.  a) certainly is more  
attractive towards having a common data format back in GDS such that a  
single web tool is capable of reporting from the data and being able  
to make conherent sense out of the data (vs. 3rd party tools that put  
data back in GDS that may not be in exactly the same format / layout  
and therefore our web reporter may not be able to make sense out of  
the data and report on it).


I think that having a Reporter/GDS.pm that system()'s the back-end  
python script gives the best of both worlds -- the MTT client can  
[continue to] submit results in the normal way, but there's also a  
standalone script that can submit results from external tool runs  
(e.g., manually running Fluent, parsing the results, and submitting to  
our GDS).  And hopefully the back-end python script will enforce a  
specific structure to the data that is submitted so that all tools --  
MTT and any 3rd party tools -- adhere to the same format and the  
reporter can therefore report

Re: [MTT devel] GSOC application

[Mike Dubman]

Hello Ethan,


On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove wrote:

>
> Will this translate to something like
> lib/MTT/Reporter/GoogleDatabase.pm?  If we are to move away from the
> current MTT Postgres database, we want to be able to submit results to
> both the current MTT database and the new Google database during the
> transition period. Having a GoogleDatabase.pm would make this easier.
>

I think we should keep both storage options: current postgress and
datastore. The mtt changes will be minor to support datastore.
Due that fact that google appengine API (as well as datastore API) can be
python or java only, we will create external scripts to manipulate datastore
objects:

The mtt will dump test results in xml format. Then, we provide two python
(or java?) scripts:

mtt-results-submit-to-datastore.py - script will be called at the end of mtt
run and will read xml files, create objects and save to datastore
mtt-results-query.py - sample script to query datastore and generate some
simple visual/tabular reports. It will serve as tutorial for howto access
mtt data from scripts for reporting.

Later, we add another script to replace php web frontend. It will be hosted
on google appengine machines and will provide web viewer for mtt results.
(same way like index.php does today)



>
> >
> >  b. mtt_save_to_db.py - script which will go over mtt scratch dir,
> find
> >  all xml files generated for every mtt phase, parse it and save to
> >  datastore, preserving test results relations,i.e. all test results
> will
> >  be grouped by mtt general info: mpi version, name, date, 
> >
> >  c. same script can scan, parse and save from xml files generated by
> >  wrapper scripts for non mtt based executions (fluent, ..)
> >
>
> I'm confused here.  Can't MTT be outfitted to report results of a
> Fluent run?
>


I think we can enhance mtt to be not only mpi testing platform, but also to
serve as mpi benchmarking platform. We can use datastore to keep mpi-based
benchmarking results in the same manner like mtt does for testing results.
(no changes to mtt required for that, it is just a side effect of using
datastore to keep data of any type)



>
>
> >  d. mtt_query_db.py script will be provided with basic query
> capabilities
> >  over proposed datastore object model. Most users will prefer writing
> >  custom sql-like select queries for fetching results.
> >
> >  3. Important notes:
> >  ==
> >
> >  a. The single mtt client execution generates many result files,
> every
> >  generated file represents test phase. This file contains test
> results
> >  and can be characterized as a set of attributes with its values.
> Every
> >  test phase has its own attributes which are differ for different
> phases.
> >  For example: attributes for TestBuild phase has keys "compiler_name,
> >  compiler_version", the MPIInstall phase has attributes: prefix_dir,
> >  arch, 
> >  Hence, most of the datastore objects representing phases of MTT* are
> >  derived from "db.Expando" model, which allows having dynamic
> attributes
> >  for its derived sub-classes.
> >
> >  The attached is archive with a simple test for using datastore for
> mtt.
> >  Please see models.py file with proposed object model and comment.
> >
>
> I don't see the models.py attachment.
>

I just sent original email with attachment, tell me if you want me to send
it again.

>
>
regards

Mike

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Mon, Apr/13/2009 04:15:23PM, Mike Dubman wrote:
>Hello Guys,
> 
>Please comment on the proposed object model and flows. We will have 1-2
>ppl working on this in a 2-3w. Till that moment I would like to finalize
>the scope and flows.
> 
>Thanks
> 
>Mike.
> 
>On Mon, Apr 6, 2009 at 4:54 PM, Mike Dubman  wrote:
> 
>  Hello Guys,
> 
>  I have played a bit with google datastore and here is a proposal for mtt
>  DB infra and some accompanying tools for submission and querying:
> 
>  1. Scope and requirements
>  
> 
>  a. provide storage services for storing test results generated by mtt.
>  Storage services will be implemented over datastore.
>  b. provide storage services for storing benchmarking results generated
>  by various mpi based applications* (not mtt based, for example: fluent,
>  openfoam)
>  c. test or benchmarking results stored in the datastore can be grouped
>  and referred as a group (for example: mtt execution can generate many
>  mtt results consisting of different phases. This mtt execution will be
>  referred as a session)
>  d. Benchmarking and test results which are generated by mtt or any other
>  mpi based applications, can be stored in the datastore and grouped by
>  some logical criteria.
>  e. The mtt should not depend or call directly any datastore`s provided
>  APIs. The mtt client (or framework/scripts executing mpi based
>  applications) should generate test/benchmarking results in some internal
>  format, which will be processed later by external tools. These external
>  tools will be responsible for saving test results in the datastore. Same
>  rules should be applied for non mtt based executions of mpi-based
>  applications (line fluent, openfoam,...). The scripts which are wrapping
>  such executions will dump benchmarking results in some internal form for
>  later processing by external tools.
> 
>  f. The internal form for representation of test/benchmarking results can
>  be XML. The external tool will receive (as cmd line params) XML files,
>  process them and save to the datastore.
> 
>  d. The external tools will be familiar with datastore object model and
>  will provide bridge between test results (XML) and actual datastore.
> 
>  2. Flow and use-cases
>  =
> 
>  a. The mtt client will dump all test related information into XML file.
>  The file will be created for every phase executed by mtt. (today there
>  are many summary txt and html files generated for every test phase, it
>  is pretty easy to add xml generation of the same information)


Will this translate to something like
lib/MTT/Reporter/GoogleDatabase.pm?  If we are to move away from the
current MTT Postgres database, we want to be able to submit results to
both the current MTT database and the new Google database during the
transition period. Having a GoogleDatabase.pm would make this easier.

> 
>  b. mtt_save_to_db.py - script which will go over mtt scratch dir, find
>  all xml files generated for every mtt phase, parse it and save to
>  datastore, preserving test results relations,i.e. all test results will
>  be grouped by mtt general info: mpi version, name, date, 
> 
>  c. same script can scan, parse and save from xml files generated by
>  wrapper scripts for non mtt based executions (fluent, ..)
>

I'm confused here.  Can't MTT be outfitted to report results of a
Fluent run?


>  d. mtt_query_db.py script will be provided with basic query capabilities
>  over proposed datastore object model. Most users will prefer writing
>  custom sql-like select queries for fetching results.
> 
>  3. Important notes:
>  ==
> 
>  a. The single mtt client execution generates many result files, every
>  generated file represents test phase. This file contains test results
>  and can be characterized as a set of attributes with its values. Every
>  test phase has its own attributes which are differ for different phases.
>  For example: attributes for TestBuild phase has keys "compiler_name,
>  compiler_version", the MPIInstall phase has attributes: prefix_dir,
>  arch, 
>  Hence, most of the datastore objects representing phases of MTT* are
>  derived from "db.Expando" model, which allows having dynamic attributes
>  for its derived sub-classes.
> 
>  The attached is archive with a simple test for using datastore for mtt.
>  Please see models.py file with proposed object model and comment.
> 

I don't see the models.py attachment.

Thanks,
Ethan


>  You can run the attached example in the google datastore dev
>  environment. (http://code.google.com/appengine/downloads.html)
> 
>  Please comment.
> 
>  Thanks
>  Mike
> 
>  On Tue, Mar 24, 2009 at 12:17 AM, Jeff Squyres 
>  

Re: [MTT devel] GSOC application

[Mike Dubman]

Hello Guys,

Please comment on the proposed object model and flows. We will have 1-2 ppl
working on this in a 2-3w. Till that moment I would like to finalize the
scope and flows.

Thanks

Mike.


On Mon, Apr 6, 2009 at 4:54 PM, Mike Dubman  wrote:

> Hello Guys,
>
> I have played a bit with google datastore and here is a proposal for mtt DB
> infra and some accompanying tools for submission and querying:
>
>
> 1. Scope and requirements
> 
>
> a. provide storage services for storing test results generated by mtt.
> Storage services will be implemented over datastore.
> b. provide storage services for storing benchmarking results generated by
> various mpi based applications  (not mtt based, for example: fluent,
> openfoam)
> c. test or benchmarking results stored in the datastore can be grouped and
> referred as a group (for example: mtt execution can generate many mtt
> results consisting of different phases. This mtt execution will be referred
> as a session)
> d. Benchmarking and test results which are generated by mtt or any other
> mpi based applications, can be stored in the datastore and grouped by some
> logical criteria.
> e. The mtt should not depend or call directly any datastore`s provided
> APIs. The mtt client (or framework/scripts executing mpi based applications)
> should generate test/benchmarking results in some internal format, which
> will be processed later by external tools. These external tools will be
> responsible for saving test results in the datastore. Same rules should be
> applied for non mtt based executions of mpi-based applications (line fluent,
> openfoam,...). The scripts which are wrapping such executions will dump
> benchmarking results in some internal form for later processing by external
> tools.
>
> f. The internal form for representation of test/benchmarking results can be
> XML. The external tool will receive (as cmd line params) XML files, process
> them and save to the datastore.
>
> d. The external tools will be familiar with datastore object model and will
> provide bridge between test results (XML) and actual datastore.
>
>
>
> 2. Flow and use-cases
> =
>
> a. The mtt client will dump all test related information into XML file. The
> file will be created for every phase executed by mtt. (today there are many
> summary txt and html files generated for every test phase, it is pretty easy
> to add xml generation of the same information)
>
> b. mtt_save_to_db.py - script which will go over mtt scratch dir, find all
> xml files generated for every mtt phase, parse it and save to datastore,
> preserving test results relations,i.e. all test results will be grouped by
> mtt general info: mpi version, name, date, 
>
> c. same script can scan, parse and save from xml files generated by wrapper
> scripts for non mtt based executions (fluent, ..)
>
> d. mtt_query_db.py script will be provided with basic query capabilities
> over proposed datastore object model. Most users will prefer writing custom
> sql-like select queries for fetching results.
>
> 3. Important notes:
> ==
>
> a. The single mtt client execution generates many result files, every
> generated file represents test phase. This file contains test results and
> can be characterized as a set of attributes with its values. Every test
> phase has its own attributes which are differ for different phases. For
> example: attributes for TestBuild phase has keys "compiler_name,
> compiler_version", the MPIInstall phase has attributes: prefix_dir, arch,
> 
> Hence, most of the datastore objects representing phases of MTT  are
> derived from "db.Expando" model, which allows having dynamic attributes for
> its derived sub-classes.
>
>
> The attached is archive with a simple test for using datastore for mtt.
> Please see models.py file with proposed object model and comment.
>
> You can run the attached example in the google datastore dev environment. (
> http://code.google.com/appengine/downloads.html)
>
> Please comment.
>
>
> Thanks
>
> Mike
>
>
>
> On Tue, Mar 24, 2009 at 12:17 AM, Jeff Squyres  wrote:
>
>> On Mar 23, 2009, at 9:05 AM, Ethan Mallove wrote:
>>
>>   ---+-+--
>>>  Resource   | Unit| Unit cost
>>>  ---+-+--
>>>  Outgoing Bandwidth | gigabytes   | $0.12
>>>  Incoming Bandwidth | gigabytes   | $0.10
>>>  CPU Time   | CPU hours   | $0.10
>>>  Stored Data| gigabytes per month | $0.15
>>>  Recipients Emailed | recipients  | $0.0001
>>>  ---+-+--
>>>
>>> Would we itemize the MTT bill on a per user basis?  E.g., orgs that
>>> use MTT more, would have to pay more?
>>>
>>>
>>
>> Let's assume stored data == incoming bandwidth, because we never throw
>> anything away.  And let's go with the SWAG of 100GB.  We may or may not be
>> able to gzip the data uploading

Re: [MTT devel] GSOC application

[Mike Dubman]

Hello Guys,

I have played a bit with google datastore and here is a proposal for mtt DB
infra and some accompanying tools for submission and querying:


1. Scope and requirements


a. provide storage services for storing test results generated by mtt.
Storage services will be implemented over datastore.
b. provide storage services for storing benchmarking results generated by
various mpi based applications  (not mtt based, for example: fluent,
openfoam)
c. test or benchmarking results stored in the datastore can be grouped and
referred as a group (for example: mtt execution can generate many mtt
results consisting of different phases. This mtt execution will be referred
as a session)
d. Benchmarking and test results which are generated by mtt or any other mpi
based applications, can be stored in the datastore and grouped by some
logical criteria.
e. The mtt should not depend or call directly any datastore`s provided APIs.
The mtt client (or framework/scripts executing mpi based applications)
should generate test/benchmarking results in some internal format, which
will be processed later by external tools. These external tools will be
responsible for saving test results in the datastore. Same rules should be
applied for non mtt based executions of mpi-based applications (line fluent,
openfoam,...). The scripts which are wrapping such executions will dump
benchmarking results in some internal form for later processing by external
tools.

f. The internal form for representation of test/benchmarking results can be
XML. The external tool will receive (as cmd line params) XML files, process
them and save to the datastore.

d. The external tools will be familiar with datastore object model and will
provide bridge between test results (XML) and actual datastore.



2. Flow and use-cases
=

a. The mtt client will dump all test related information into XML file. The
file will be created for every phase executed by mtt. (today there are many
summary txt and html files generated for every test phase, it is pretty easy
to add xml generation of the same information)

b. mtt_save_to_db.py - script which will go over mtt scratch dir, find all
xml files generated for every mtt phase, parse it and save to datastore,
preserving test results relations,i.e. all test results will be grouped by
mtt general info: mpi version, name, date, 

c. same script can scan, parse and save from xml files generated by wrapper
scripts for non mtt based executions (fluent, ..)

d. mtt_query_db.py script will be provided with basic query capabilities
over proposed datastore object model. Most users will prefer writing custom
sql-like select queries for fetching results.

3. Important notes:
==

a. The single mtt client execution generates many result files, every
generated file represents test phase. This file contains test results and
can be characterized as a set of attributes with its values. Every test
phase has its own attributes which are differ for different phases. For
example: attributes for TestBuild phase has keys "compiler_name,
compiler_version", the MPIInstall phase has attributes: prefix_dir, arch,

Hence, most of the datastore objects representing phases of MTT  are derived
from "db.Expando" model, which allows having dynamic attributes for its
derived sub-classes.


The attached is archive with a simple test for using datastore for mtt.
Please see models.py file with proposed object model and comment.

You can run the attached example in the google datastore dev environment. (
http://code.google.com/appengine/downloads.html)

Please comment.


Thanks

Mike


On Tue, Mar 24, 2009 at 12:17 AM, Jeff Squyres  wrote:

> On Mar 23, 2009, at 9:05 AM, Ethan Mallove wrote:
>
>   ---+-+--
>>  Resource   | Unit| Unit cost
>>  ---+-+--
>>  Outgoing Bandwidth | gigabytes   | $0.12
>>  Incoming Bandwidth | gigabytes   | $0.10
>>  CPU Time   | CPU hours   | $0.10
>>  Stored Data| gigabytes per month | $0.15
>>  Recipients Emailed | recipients  | $0.0001
>>  ---+-+--
>>
>> Would we itemize the MTT bill on a per user basis?  E.g., orgs that
>> use MTT more, would have to pay more?
>>
>>
>
> Let's assume stored data == incoming bandwidth, because we never throw
> anything away.  And let's go with the SWAG of 100GB.  We may or may not be
> able to gzip the data uploading to the server.  So if anything, we *might*
> be able to decrease the incoming data and have higher level of stored data.
>
> I anticipate our outgoing data to be significantly less, particularly if we
> can gzip the outgoing data (which I think we can).  You're right, CPU time
> is a mystery -- we won't know what it will be until we start running some
> queries to see what happens.
>
> 100GB * $0.10 = $10
> 100GB * $0.15 = 

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Mar 23, 2009, at 9:05 AM, Ethan Mallove wrote:


  ---+-+--
  Resource   | Unit| Unit cost
  ---+-+--
  Outgoing Bandwidth | gigabytes   | $0.12
  Incoming Bandwidth | gigabytes   | $0.10
  CPU Time   | CPU hours   | $0.10
  Stored Data| gigabytes per month | $0.15
  Recipients Emailed | recipients  | $0.0001
  ---+-+--

Would we itemize the MTT bill on a per user basis?  E.g., orgs that
use MTT more, would have to pay more?




Let's assume stored data == incoming bandwidth, because we never throw  
anything away.  And let's go with the SWAG of 100GB.  We may or may  
not be able to gzip the data uploading to the server.  So if anything,  
we *might* be able to decrease the incoming data and have higher level  
of stored data.


I anticipate our outgoing data to be significantly less, particularly  
if we can gzip the outgoing data (which I think we can).  You're  
right, CPU time is a mystery -- we won't know what it will be until we  
start running some queries to see what happens.


100GB * $0.10 = $10
100GB * $0.15 = $15
total = $25 for the first month

So let's SWAG at $25/mo for a year = $300.  This number will be wrong  
for several reasons, but it at least gives us a ballpark.  For $300/ 
year, I think we (the OMPI project) can find a way to pay for this  
fairly easily.


--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Mon, Mar/23/2009 03:53:53PM, Mike Dubman wrote:
>I'm playing with google datastore now and will send some proposal and
>thoughts.
> 
>On Mon, Mar 23, 2009 at 2:33 PM, Jeff Squyres  wrote:
> 
>  Yes, I think you're right -- making a "schema" for the datastore might
>  be quite easy. *I'm on travel all this week and likely won't be able to
>  look into this stuff -- can you guys post a proposal and we can dive
>  into it from that angle?
> 
>  On Mar 22, 2009, at 6:48 AM, Mike Dubman wrote:
> 
>Hello guys,
> 
>I`m not sure if we should preserve current DB schema, from one simple
>reason - datastore is an object oriented storage and have different
>rules and techniques then rdbms.
>The basic storage unit in the datastore is an object which can be
>saved, loaded and queried.
>(hadoop is based on the same principles, but open source.)
> 
>It seems that DB model for mtt over datastore should not be complex at
>all. The current mtt db schema is mostly optimized for specific
>queries dictated by web UI. Datastore creates indexes automatically,
>based on submitted queries history.
> 
>I suggest we discuss/exchange db layout proposals by emails and when
>we get to some general understanding how it should look like - we
>switch to telepresence.
> 
>Also, It seems not problem at all to get datastore access for existing
>gmail account. You get 500MB quota for storage. It takes 5min to start
>using it.
> 
>Here is some short info for datastore API:
>- howto submit data model to datastore
>- howto save, load, query
> 
>
> http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html
> 
>please comment.

Do we have a monthly cost estimate for this project?  We will exceed
the free quota of CPU/bandwidth/storage/email, and get billed
(depending on how efficient our App is):

  http://code.google.com/appengine/docs/billing.html

The biggest concern would be the Stored Data cost, because I like how
we can now archive lots and lots of test results. I do not have
permission to access /var/lib/pgsql/data, but weren't we at or near
100 GBs recently?  The bandwidth charge would seem to be pretty
nominal. We could upload/download 100GB/mo. for just $10/mo. and I am
not sure if we approach 100GB.  CPU Time is a a mystery number to me.

  ---+-+--
  Resource   | Unit| Unit cost
  ---+-+--
  Outgoing Bandwidth | gigabytes   | $0.12
  Incoming Bandwidth | gigabytes   | $0.10
  CPU Time   | CPU hours   | $0.10
  Stored Data| gigabytes per month | $0.15
  Recipients Emailed | recipients  | $0.0001
  ---+-+--

Would we itemize the MTT bill on a per user basis?  E.g., orgs that
use MTT more, would have to pay more?

-Ethan



> 
>Thanks
> 
>Mike
> 
>On Fri, Mar 20, 2009 at 5:38 PM, Jeff Squyres 
>wrote:
>On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:
> 
>Yeah I think this sounds like a good way to move forward with this
>work. The database schema is pretty complex. If you need help on the
>database side of things let me know.
> 
>To get started, would it be useful to have a meeting over the phone/
>telepresence to design the datastore layout? This gives us an
>opportunity to start from a blank slate with regards to the
>datastore, so it may be useful brainstorm a bit beforehand.
> 
>Yes, it probably would. *My understanding of hadoop (which is very
>highlevel) is that just dump everything in without too much concern
>about the structure / "schema". *But I could be wrong on that.
> 
>The Google Apps account is under my personal Google account,
>so I am
>reluctant to use it. I think the reason it took so long for me, was
>because when I originally signed up it was in limited beta. I think
>the approval time is much shorter now (maybe a day?), and we can make
>an openmpi or mtt account that we can use.
> 
>With regard to Hadoop, I don't think that IU has a set of machines
>that would work, but I can ask around. We could always try Hadoop on
>a single machine if people wanted to play around with data querying/
>storage.
> 
>I don't have a strong preference either way, but Google Apps may
>provide us with a lower overhead solution for the long run even
>though it costs $$.
> 
>It looks like there is a set that you can use for free. *When you go
>over one of several metrics (CPU hours/day, storage, bandwidth in,
>bandwidth out, etc.), then you have to start paying. *But even

Re: [MTT devel] GSOC application

[Mike Dubman]

I'm playing with google datastore now and will send some proposal and
thoughts.

On Mon, Mar 23, 2009 at 2:33 PM, Jeff Squyres  wrote:

> Yes, I think you're right -- making a "schema" for the datastore might be
> quite easy.  I'm on travel all this week and likely won't be able to look
> into this stuff -- can you guys post a proposal and we can dive into it from
> that angle?
>
>
> On Mar 22, 2009, at 6:48 AM, Mike Dubman wrote:
>
>  Hello guys,
>>
>> I`m not sure if we should preserve current DB schema, from one simple
>> reason - datastore is an object oriented storage and have different rules
>> and techniques then rdbms.
>> The basic storage unit in the datastore is an object which can be saved,
>> loaded and queried.
>> (hadoop is based on the same principles, but open source.)
>>
>> It seems that DB model for mtt over datastore should not be complex at
>> all. The current mtt db schema is mostly optimized for specific queries
>> dictated by web UI. Datastore creates indexes automatically, based on
>> submitted queries history.
>>
>> I suggest we discuss/exchange db layout proposals by emails and when we
>> get to some general understanding how it should look like - we switch to
>> telepresence.
>>
>> Also, It seems not problem at all to get datastore access for existing
>> gmail account. You get 500MB quota for storage. It takes 5min to start using
>> it.
>>
>> Here is some short info for datastore API:
>> - howto submit data model to datastore
>> - howto save, load, query
>>
>>
>> http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html
>>
>> please comment.
>>
>> Thanks
>>
>> Mike
>>
>> On Fri, Mar 20, 2009 at 5:38 PM, Jeff Squyres  wrote:
>> On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:
>>
>> Yeah I think this sounds like a good way to move forward with this
>> work. The database schema is pretty complex. If you need help on the
>> database side of things let me know.
>>
>> To get started, would it be useful to have a meeting over the phone/
>> telepresence to design the datastore layout? This gives us an
>> opportunity to start from a blank slate with regards to the
>> datastore, so it may be useful brainstorm a bit beforehand.
>>
>>
>> Yes, it probably would.  My understanding of hadoop (which is very
>> highlevel) is that just dump everything in without too much concern about
>> the structure / "schema".  But I could be wrong on that.
>>
>>
>> The Google Apps account is under my personal Google account, so I'm
>> reluctant to use it. I think the reason it took so long for me, was
>> because when I originally signed up it was in limited beta. I think
>> the approval time is much shorter now (maybe a day?), and we can make
>> an openmpi or mtt account that we can use.
>>
>> With regard to Hadoop, I don't think that IU has a set of machines
>> that would work, but I can ask around. We could always try Hadoop on
>> a single machine if people wanted to play around with data querying/
>> storage.
>>
>> I don't have a strong preference either way, but Google Apps may
>> provide us with a lower overhead solution for the long run even
>> though it costs $$.
>>
>>
>>
>> It looks like there is a set that you can use for free.  When you go over
>> one of several metrics (CPU hours/day, storage, bandwidth in, bandwidth out,
>> etc.), then you have to start paying.  But even with that, the costs look
>> *quite* reasonable and should be easily covered by the combined Open MPI
>> organizations (I'm talking hundreds of dollars here, not tens of thousands).
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>

Re: [MTT devel] GSOC application

[Josh Hursey]

The next 2 weeks are pretty tight for me. I'll try to take a look at  
the API and send some comments as soon as I am able.


-- Josh

On Mar 23, 2009, at 8:33 AM, Jeff Squyres wrote:

Yes, I think you're right -- making a "schema" for the datastore  
might be quite easy.  I'm on travel all this week and likely won't  
be able to look into this stuff -- can you guys post a proposal and  
we can dive into it from that angle?


On Mar 22, 2009, at 6:48 AM, Mike Dubman wrote:


Hello guys,

I`m not sure if we should preserve current DB schema, from one  
simple reason - datastore is an object oriented storage and have  
different rules and techniques then rdbms.
The basic storage unit in the datastore is an object which can be  
saved, loaded and queried.

(hadoop is based on the same principles, but open source.)

It seems that DB model for mtt over datastore should not be complex  
at all. The current mtt db schema is mostly optimized for specific  
queries dictated by web UI. Datastore creates indexes  
automatically, based on submitted queries history.


I suggest we discuss/exchange db layout proposals by emails and  
when we get to some general understanding how it should look like -  
we switch to telepresence.


Also, It seems not problem at all to get datastore access for  
existing gmail account. You get 500MB quota for storage. It takes  
5min to start using it.


Here is some short info for datastore API:
- howto submit data model to datastore
- howto save, load, query

http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html

please comment.

Thanks

Mike

On Fri, Mar 20, 2009 at 5:38 PM, Jeff Squyres   
wrote:

On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:

Yeah I think this sounds like a good way to move forward with this
work. The database schema is pretty complex. If you need help on the
database side of things let me know.

To get started, would it be useful to have a meeting over the phone/
telepresence to design the datastore layout? This gives us an
opportunity to start from a blank slate with regards to the
datastore, so it may be useful brainstorm a bit beforehand.


Yes, it probably would.  My understanding of hadoop (which is very  
highlevel) is that just dump everything in without too much concern  
about the structure / "schema".  But I could be wrong on that.



The Google Apps account is under my personal Google account, so I'm
reluctant to use it. I think the reason it took so long for me, was
because when I originally signed up it was in limited beta. I think
the approval time is much shorter now (maybe a day?), and we can make
an openmpi or mtt account that we can use.

With regard to Hadoop, I don't think that IU has a set of machines
that would work, but I can ask around. We could always try Hadoop on
a single machine if people wanted to play around with data querying/
storage.

I don't have a strong preference either way, but Google Apps may
provide us with a lower overhead solution for the long run even
though it costs $$.



It looks like there is a set that you can use for free.  When you  
go over one of several metrics (CPU hours/day, storage, bandwidth  
in, bandwidth out, etc.), then you have to start paying.  But even  
with that, the costs look *quite* reasonable and should be easily  
covered by the combined Open MPI organizations (I'm talking  
hundreds of dollars here, not tens of thousands).



--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Jeff Squyres]

Yes, I think you're right -- making a "schema" for the datastore might  
be quite easy.  I'm on travel all this week and likely won't be able  
to look into this stuff -- can you guys post a proposal and we can  
dive into it from that angle?


On Mar 22, 2009, at 6:48 AM, Mike Dubman wrote:


Hello guys,

I`m not sure if we should preserve current DB schema, from one  
simple reason - datastore is an object oriented storage and have  
different rules and techniques then rdbms.
The basic storage unit in the datastore is an object which can be  
saved, loaded and queried.

(hadoop is based on the same principles, but open source.)

It seems that DB model for mtt over datastore should not be complex  
at all. The current mtt db schema is mostly optimized for specific  
queries dictated by web UI. Datastore creates indexes automatically,  
based on submitted queries history.


I suggest we discuss/exchange db layout proposals by emails and when  
we get to some general understanding how it should look like - we  
switch to telepresence.


Also, It seems not problem at all to get datastore access for  
existing gmail account. You get 500MB quota for storage. It takes  
5min to start using it.


Here is some short info for datastore API:
- howto submit data model to datastore
- howto save, load, query

http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html

please comment.

Thanks

Mike

On Fri, Mar 20, 2009 at 5:38 PM, Jeff Squyres   
wrote:

On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:

Yeah I think this sounds like a good way to move forward with this
work. The database schema is pretty complex. If you need help on the
database side of things let me know.

To get started, would it be useful to have a meeting over the phone/
telepresence to design the datastore layout? This gives us an
opportunity to start from a blank slate with regards to the
datastore, so it may be useful brainstorm a bit beforehand.


Yes, it probably would.  My understanding of hadoop (which is very  
highlevel) is that just dump everything in without too much concern  
about the structure / "schema".  But I could be wrong on that.



The Google Apps account is under my personal Google account, so I'm
reluctant to use it. I think the reason it took so long for me, was
because when I originally signed up it was in limited beta. I think
the approval time is much shorter now (maybe a day?), and we can make
an openmpi or mtt account that we can use.

With regard to Hadoop, I don't think that IU has a set of machines
that would work, but I can ask around. We could always try Hadoop on
a single machine if people wanted to play around with data querying/
storage.

I don't have a strong preference either way, but Google Apps may
provide us with a lower overhead solution for the long run even
though it costs $$.



It looks like there is a set that you can use for free.  When you go  
over one of several metrics (CPU hours/day, storage, bandwidth in,  
bandwidth out, etc.), then you have to start paying.  But even with  
that, the costs look *quite* reasonable and should be easily covered  
by the combined Open MPI organizations (I'm talking hundreds of  
dollars here, not tens of thousands).



--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

Hello guys,

I`m not sure if we should preserve current DB schema, from one simple reason
- datastore is an object oriented storage and have different rules and
techniques then rdbms.
The basic storage unit in the datastore is an object which can be saved,
loaded and queried.
(hadoop is based on the same principles, but open source.)

It seems that DB model for mtt over datastore should not be complex at all.
The current mtt db schema is mostly optimized for specific queries dictated
by web UI. Datastore creates indexes automatically, based on submitted
queries history.

I suggest we discuss/exchange db layout proposals by emails and when we get
to some general understanding how it should look like - we switch to
telepresence.

Also, It seems not problem at all to get datastore access for existing gmail
account. You get 500MB quota for storage. It takes 5min to start using it.

Here is some short info for datastore API:
- howto submit data model to datastore
- howto save, load, query

http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html

please comment.

Thanks

Mike

On Fri, Mar 20, 2009 at 5:38 PM, Jeff Squyres  wrote:

> On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:
>
>  Yeah I think this sounds like a good way to move forward with this
>> work. The database schema is pretty complex. If you need help on the
>> database side of things let me know.
>>
>> To get started, would it be useful to have a meeting over the phone/
>> telepresence to design the datastore layout? This gives us an
>> opportunity to start from a blank slate with regards to the
>> datastore, so it may be useful brainstorm a bit beforehand.
>>
>>
> Yes, it probably would.  My understanding of hadoop (which is very
> highlevel) is that just dump everything in without too much concern about
> the structure / "schema".  But I could be wrong on that.
>
>  The Google Apps account is under my personal Google account, so I'm
>> reluctant to use it. I think the reason it took so long for me, was
>> because when I originally signed up it was in limited beta. I think
>> the approval time is much shorter now (maybe a day?), and we can make
>> an openmpi or mtt account that we can use.
>>
>> With regard to Hadoop, I don't think that IU has a set of machines
>> that would work, but I can ask around. We could always try Hadoop on
>> a single machine if people wanted to play around with data querying/
>> storage.
>>
>> I don't have a strong preference either way, but Google Apps may
>> provide us with a lower overhead solution for the long run even
>> though it costs $$.
>>
>>
>
> It looks like there is a set that you can use for free.  When you go over
> one of several metrics (CPU hours/day, storage, bandwidth in, bandwidth out,
> etc.), then you have to start paying.  But even with that, the costs look
> *quite* reasonable and should be easily covered by the combined Open MPI
> organizations (I'm talking hundreds of dollars here, not tens of thousands).
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Mar 20, 2009, at 10:42 AM, Josh Hursey wrote:


Yeah I think this sounds like a good way to move forward with this
work. The database schema is pretty complex. If you need help on the
database side of things let me know.

To get started, would it be useful to have a meeting over the phone/
telepresence to design the datastore layout? This gives us an
opportunity to start from a blank slate with regards to the
datastore, so it may be useful brainstorm a bit beforehand.



Yes, it probably would.  My understanding of hadoop (which is very  
highlevel) is that just dump everything in without too much concern  
about the structure / "schema".  But I could be wrong on that.



The Google Apps account is under my personal Google account, so I'm
reluctant to use it. I think the reason it took so long for me, was
because when I originally signed up it was in limited beta. I think
the approval time is much shorter now (maybe a day?), and we can make
an openmpi or mtt account that we can use.

With regard to Hadoop, I don't think that IU has a set of machines
that would work, but I can ask around. We could always try Hadoop on
a single machine if people wanted to play around with data querying/
storage.

I don't have a strong preference either way, but Google Apps may
provide us with a lower overhead solution for the long run even
though it costs $$.




It looks like there is a set that you can use for free.  When you go  
over one of several metrics (CPU hours/day, storage, bandwidth in,  
bandwidth out, etc.), then you have to start paying.  But even with  
that, the costs look *quite* reasonable and should be easily covered  
by the combined Open MPI organizations (I'm talking hundreds of  
dollars here, not tens of thousands).


--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Josh Hursey]

Yeah I think this sounds like a good way to move forward with this  
work. The database schema is pretty complex. If you need help on the  
database side of things let me know.


To get started, would it be useful to have a meeting over the phone/ 
telepresence to design the datastore layout? This gives us an  
opportunity to start from a blank slate with regards to the  
datastore, so it may be useful brainstorm a bit beforehand.


The Google Apps account is under my personal Google account, so I'm  
reluctant to use it. I think the reason it took so long for me, was  
because when I originally signed up it was in limited beta. I think  
the approval time is much shorter now (maybe a day?), and we can make  
an openmpi or mtt account that we can use.


With regard to Hadoop, I don't think that IU has a set of machines  
that would work, but I can ask around. We could always try Hadoop on  
a single machine if people wanted to play around with data querying/ 
storage.


I don't have a strong preference either way, but Google Apps may  
provide us with a lower overhead solution for the long run even  
though it costs $$.


Cheers,
Josh

On Mar 19, 2009, at 11:06 AM, Jeff Squyres wrote:


On Mar 19, 2009, at 10:51 AM, Mike Dubman wrote:

I think we can switch to desired framework (datastore+mapreduce)  
gradually in the background:

Here is a short battle plan:

1. create datastore (google`s or similar)
2. design datastore layout (what to keep, how to keep, objects &  
attributes)

3. create cmd line tool to submit results into datastore
4. integrate (3) into mtt
5. Milestone: we have tool to submit run results into two DBs  
(currents & datastore)


Agreed -- this is very do-able.

6. Create mpi-aware cmd line tool to query submitted results. Tool  
should allow query and fetch selected results.
7. Milestone: we have cmd line tool to query performance results.  
This tool can be used by community to play with custom scripts for  
fetching results and generating custom reports.


8. here we can collect 3rd party/contributed scripts to create  
various visual reports based on perf results.


what do you think?

I think we can provide some dark forces here to perform most of  
the steps.


Awesome!  I can say that if this stuff becomes available, Cisco  
will start "double submitting" -- do the currently-official  
postgres db (i.e., same as today), and to the new/experimental  
datastore.


Will it be possible to host datastore on openmpi.org and open  
access to it?



I think we have 2 options here:

1. Google's datastore/app engine.  That requires signing up for a  
Google Apps account with Google Engine access.  Josh has one of  
these (anyone can get a Google Apps account; as I understand it,  
you have to apply for Google Engine access and approval can take a  
long time -- Josh just got approved after nearly a year).  Josh  
-- could we use your account, perchance?  (I'm not sure if this is  
Josh's main/personal Google account, or a generic account he created)


2. Hadoop.  This is the open source project that is modeled off  
Google's papers that they published about map/reduce.  We'd have to  
host the hadoop data store somewhere (e.g., IU), but it benefits  
from having multiple machines to store data, such as a data farm.   
I do not believe that IU has such a resource.


There are definite similarities between the two choices, but I  
believe the APIs are different -- so we have to code for one or the  
other.


I think I would prefer #1 in order to take care of the hosting  
issue.  If we get past the proof-of-concept stage, I'm guessing  
it'll be pretty easy to get the funding to get a real Google Apps  
account (it's $50/user/year -- darn cheap).


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Mar 19, 2009, at 11:06 AM, Jeff Squyres wrote:

1. Google's datastore/app engine.  That requires signing up for a  
Google Apps account with Google Engine access.  Josh has one of  
these (anyone can get a Google Apps account; as I understand it, you  
have to apply for Google Engine access and approval can take a  
long time -- Josh just got approved after nearly a year).  Josh  
-- could we use your account, perchance?  (I'm not sure if this is  
Josh's main/personal Google account, or a generic account he created)



I take this back -- I just used my own Google Account to apply for an  
App Engine account and (I think) it was approved immediately.  So I  
think App Engine accounts are readily available these days; we can get  
an "openmpi" Google Account with an associated Google App Engine  
account, or somesuch.


--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Jeff Squyres]

On Mar 19, 2009, at 10:51 AM, Mike Dubman wrote:

I think we can switch to desired framework (datastore+mapreduce)  
gradually in the background:

Here is a short battle plan:

1. create datastore (google`s or similar)
2. design datastore layout (what to keep, how to keep, objects &  
attributes)

3. create cmd line tool to submit results into datastore
4. integrate (3) into mtt
5. Milestone: we have tool to submit run results into two DBs  
(currents & datastore)


Agreed -- this is very do-able.

6. Create mpi-aware cmd line tool to query submitted results. Tool  
should allow query and fetch selected results.
7. Milestone: we have cmd line tool to query performance results.  
This tool can be used by community to play with custom scripts for  
fetching results and generating custom reports.


8. here we can collect 3rd party/contributed scripts to create  
various visual reports based on perf results.


what do you think?

I think we can provide some dark forces here to perform most of the  
steps.


Awesome!  I can say that if this stuff becomes available, Cisco will  
start "double submitting" -- do the currently-official postgres db  
(i.e., same as today), and to the new/experimental datastore.


Will it be possible to host datastore on openmpi.org and open access  
to it?



I think we have 2 options here:

1. Google's datastore/app engine.  That requires signing up for a  
Google Apps account with Google Engine access.  Josh has one of these  
(anyone can get a Google Apps account; as I understand it, you have to  
apply for Google Engine access and approval can take a long time  
-- Josh just got approved after nearly a year).  Josh -- could we use  
your account, perchance?  (I'm not sure if this is Josh's main/ 
personal Google account, or a generic account he created)


2. Hadoop.  This is the open source project that is modeled off  
Google's papers that they published about map/reduce.  We'd have to  
host the hadoop data store somewhere (e.g., IU), but it benefits from  
having multiple machines to store data, such as a data farm.  I do not  
believe that IU has such a resource.


There are definite similarities between the two choices, but I believe  
the APIs are different -- so we have to code for one or the other.


I think I would prefer #1 in order to take care of the hosting issue.   
If we get past the proof-of-concept stage, I'm guessing it'll be  
pretty easy to get the funding to get a real Google Apps account (it's  
$50/user/year -- darn cheap).


--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Mike Dubman]

 I think we can switch to desired framework (datastore+mapreduce) gradually
in the background:
Here is a short battle plan:

1. create datastore (google`s or similar)
2. design datastore layout (what to keep, how to keep, objects & attributes)
3. create cmd line tool to submit results into datastore
4. integrate (3) into mtt
5. Milestone: we have tool to submit run results into two DBs (currents &
datastore)
6. Create mpi-aware cmd line tool to query submitted results. Tool should
allow query and fetch selected results.
7. Milestone: we have cmd line tool to query performance results. This tool
can be used by community to play with custom scripts for fetching results
and generating custom reports.

8. here we can collect 3rd party/contributed scripts to create various
visual reports based on perf results.

what do you think?

I think we can provide some dark forces here to perform most of the steps.
Will it be possible to host datastore on openmpi.org and open access to it?







On Wed, Mar 18, 2009 at 10:05 PM, Ethan Mallove wrote:

> On Wed, Mar/18/2009 03:28:48PM, Josh Hursey wrote:
> > So they posted the list of accepted projects and we are -not- on it
> > for this year:
> >
> >   http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
> >
> > Maybe next year. I don't know if they will be sending around a note
> > regarding why we were not selected to participate. If they do I will
> > forward it along.
>
> Thanks, Josh.
>
> I'm reading that in 2008, they only accepted 174 out of the 7100
> applications.
>
> -Ethan
>
> >
> > Cheers,
> > Josh
> >
> > On Mar 13, 2009, at 3:19 PM, Jeff Squyres wrote:
> >
> >> Awesome; many thanks for carrying the baton over the finish line, Josh!
> >>
> >> On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:
> >>
> >>> The application has been submitted. We find out on March 18 (3 pm) if
> >>> we have been accepted. Link to timeline below:
> >>>http://socghop.appspot.com/document/show/program/google/gsoc2009/
> >>> timeline
> >>>
> >>> Cheers,
> >>> Josh
> >>>
> >>> On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:
> >>>
> >>> > I just pushed a final draft to the repository. I'll probably plan
> >>> > on submitting at 2:30/2:45. Let me know if you have any edits
> >>> > before then either through email or IM.
> >>> >
> >>> > Cheers,
> >>> > Josh
> >>> >
> >>> > On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
> >>> >
> >>> >> I finished a first pass at cleaning up the Ideas page on the Wiki.
> >>> >> All of the ideas were preserved, just some rewording and formatting.
> >>> >>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
> >>> >>
> >>> >> If you get a chance, read through this and make sure the text
> >>> >> sounds ok (feel free to clean the text up as necessary).
> >>> >>
> >>> >> The application is due by 3 pm EST. So I hope to have the
> >>> >> application ready by 2ish. I'll move onto the application itself
> now.
> >>> >>
> >>> >> -- Josh
> >>> >>
> >>> >> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
> >>> >>
> >>> >>> Jeff is going to take the first pass at the application.
> >>> >>>
> >>> >>> I am going to go through the Idea page on the wiki and polish a
> bit:
> >>> >>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
> >>> >>>
> >>> >>> I'll let folks know when I'm done, and we can start iterating on
> >>> >>> drafts.
> >>> >>>
> >>> >>> Cheers,
> >>> >>> Josh
> >>> >>>
> >>> >>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
> >>> >>>
> >>>  I've created a quick-n-dirty hg to collaborate on the GSOC
> >>>  application.  There's a web form to fill out to apply, so let's
> >>>  work on a .txt file in the hg to get it right.
> >>> 
> >>>  We have until 3pm US Eastern time tomorrow to submit.  Here's
> >>>  the HG:
> >>> 
> >>> 
> >>>  ssh://www.open-mpi.org/~jsquyres/hg/gsoc/
> >>> 
> >>>  I've put the PDF there for now; I'll kruft up a quick .txt
> >>>  shortly and push it there as well.
> >>> 
> >>>  --
> >>>  Jeff Squyres
> >>>  Cisco Systems
> >>> 
> >>>  ___
> >>>  mtt-devel mailing list
> >>>  mtt-de...@open-mpi.org
> >>>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >>> >>>
> >>> >>> ___
> >>> >>> mtt-devel mailing list
> >>> >>> mtt-de...@open-mpi.org
> >>> >>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >>> >>
> >>> >> ___
> >>> >> mtt-devel mailing list
> >>> >> mtt-de...@open-mpi.org
> >>> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >>> >
> >>> > ___
> >>> > mtt-devel mailing list
> >>> > mtt-de...@open-mpi.org
> >>> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> >>>
> >>> ___
> >>> mtt-devel mailing list
> >>> mt

Re: [MTT devel] GSOC application

[Jeff Squyres]

Looks like there were 400 applications this year; they selected 150 --  
38%.  We were in the unlucky 62%.  Bummer.


On Mar 18, 2009, at 4:05 PM, Ethan Mallove wrote:


On Wed, Mar/18/2009 03:28:48PM, Josh Hursey wrote:
> So they posted the list of accepted projects and we are -not- on it
> for this year:
>
>   http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
>
> Maybe next year. I don't know if they will be sending around a note
> regarding why we were not selected to participate. If they do I will
> forward it along.

Thanks, Josh.

I'm reading that in 2008, they only accepted 174 out of the 7100
applications.

-Ethan

>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 3:19 PM, Jeff Squyres wrote:
>
>> Awesome; many thanks for carrying the baton over the finish line,  
Josh!

>>
>> On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:
>>
>>> The application has been submitted. We find out on March 18 (3  
pm) if

>>> we have been accepted. Link to timeline below:
>>>http://socghop.appspot.com/document/show/program/google/gsoc2009/
>>> timeline
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:
>>>
>>> > I just pushed a final draft to the repository. I'll probably  
plan

>>> > on submitting at 2:30/2:45. Let me know if you have any edits
>>> > before then either through email or IM.
>>> >
>>> > Cheers,
>>> > Josh
>>> >
>>> > On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>>> >
>>> >> I finished a first pass at cleaning up the Ideas page on the  
Wiki.
>>> >> All of the ideas were preserved, just some rewording and  
formatting.

>>> >>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>
>>> >> If you get a chance, read through this and make sure the text
>>> >> sounds ok (feel free to clean the text up as necessary).
>>> >>
>>> >> The application is due by 3 pm EST. So I hope to have the
>>> >> application ready by 2ish. I'll move onto the application  
itself now.

>>> >>
>>> >> -- Josh
>>> >>
>>> >> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>> >>
>>> >>> Jeff is going to take the first pass at the application.
>>> >>>
>>> >>> I am going to go through the Idea page on the wiki and  
polish a bit:

>>> >>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>>
>>> >>> I'll let folks know when I'm done, and we can start  
iterating on

>>> >>> drafts.
>>> >>>
>>> >>> Cheers,
>>> >>> Josh
>>> >>>
>>> >>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>> >>>
>>>  I've created a quick-n-dirty hg to collaborate on the GSOC
>>>  application.  There's a web form to fill out to apply, so  
let's

>>>  work on a .txt file in the hg to get it right.
>>> 
>>>  We have until 3pm US Eastern time tomorrow to submit.  Here's
>>>  the HG:
>>> 
>>> ssh://www.open-mpi.org/~jsquyres/hg/gsoc/
>>> 
>>>  I've put the PDF there for now; I'll kruft up a quick .txt
>>>  shortly and push it there as well.
>>> 
>>>  --
>>>  Jeff Squyres
>>>  Cisco Systems
>>> 
>>>  ___
>>>  mtt-devel mailing list
>>>  mtt-de...@open-mpi.org
>>>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>>
>>> >>> ___
>>> >>> mtt-devel mailing list
>>> >>> mtt-de...@open-mpi.org
>>> >>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>
>>> >> ___
>>> >> mtt-devel mailing list
>>> >> mtt-de...@open-mpi.org
>>> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >
>>> > ___
>>> > mtt-devel mailing list
>>> > mtt-de...@open-mpi.org
>>> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Wed, Mar/18/2009 03:28:48PM, Josh Hursey wrote:
> So they posted the list of accepted projects and we are -not- on it
> for this year:
>
>   http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
>
> Maybe next year. I don't know if they will be sending around a note
> regarding why we were not selected to participate. If they do I will
> forward it along.

Thanks, Josh.

I'm reading that in 2008, they only accepted 174 out of the 7100
applications.

-Ethan

>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 3:19 PM, Jeff Squyres wrote:
>
>> Awesome; many thanks for carrying the baton over the finish line, Josh!
>>
>> On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:
>>
>>> The application has been submitted. We find out on March 18 (3 pm) if
>>> we have been accepted. Link to timeline below:
>>>http://socghop.appspot.com/document/show/program/google/gsoc2009/
>>> timeline
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:
>>>
>>> > I just pushed a final draft to the repository. I'll probably plan
>>> > on submitting at 2:30/2:45. Let me know if you have any edits
>>> > before then either through email or IM.
>>> >
>>> > Cheers,
>>> > Josh
>>> >
>>> > On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>>> >
>>> >> I finished a first pass at cleaning up the Ideas page on the Wiki.
>>> >> All of the ideas were preserved, just some rewording and formatting.
>>> >>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>
>>> >> If you get a chance, read through this and make sure the text
>>> >> sounds ok (feel free to clean the text up as necessary).
>>> >>
>>> >> The application is due by 3 pm EST. So I hope to have the
>>> >> application ready by 2ish. I'll move onto the application itself now.
>>> >>
>>> >> -- Josh
>>> >>
>>> >> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>> >>
>>> >>> Jeff is going to take the first pass at the application.
>>> >>>
>>> >>> I am going to go through the Idea page on the wiki and polish a bit:
>>> >>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>> >>>
>>> >>> I'll let folks know when I'm done, and we can start iterating on
>>> >>> drafts.
>>> >>>
>>> >>> Cheers,
>>> >>> Josh
>>> >>>
>>> >>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>> >>>
>>>  I've created a quick-n-dirty hg to collaborate on the GSOC
>>>  application.  There's a web form to fill out to apply, so let's
>>>  work on a .txt file in the hg to get it right.
>>> 
>>>  We have until 3pm US Eastern time tomorrow to submit.  Here's
>>>  the HG:
>>> 
>>> ssh://www.open-mpi.org/~jsquyres/hg/gsoc/
>>> 
>>>  I've put the PDF there for now; I'll kruft up a quick .txt
>>>  shortly and push it there as well.
>>> 
>>>  --
>>>  Jeff Squyres
>>>  Cisco Systems
>>> 
>>>  ___
>>>  mtt-devel mailing list
>>>  mtt-de...@open-mpi.org
>>>  http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>>
>>> >>> ___
>>> >>> mtt-devel mailing list
>>> >>> mtt-de...@open-mpi.org
>>> >>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >>
>>> >> ___
>>> >> mtt-devel mailing list
>>> >> mtt-de...@open-mpi.org
>>> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>> >
>>> > ___
>>> > mtt-devel mailing list
>>> > mtt-de...@open-mpi.org
>>> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>>
>> -- 
>> Jeff Squyres
>> Cisco Systems
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Josh Hursey]

So they posted the list of accepted projects and we are -not- on it  
for this year:

  http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009

Maybe next year. I don't know if they will be sending around a note  
regarding why we were not selected to participate. If they do I will  
forward it along.


Cheers,
Josh

On Mar 13, 2009, at 3:19 PM, Jeff Squyres wrote:

Awesome; many thanks for carrying the baton over the finish line,  
Josh!


On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:


The application has been submitted. We find out on March 18 (3 pm) if
we have been accepted. Link to timeline below:
   http://socghop.appspot.com/document/show/program/google/gsoc2009/
timeline

Cheers,
Josh

On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:

> I just pushed a final draft to the repository. I'll probably plan
> on submitting at 2:30/2:45. Let me know if you have any edits
> before then either through email or IM.
>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>
>> I finished a first pass at cleaning up the Ideas page on the Wiki.
>> All of the ideas were preserved, just some rewording and  
formatting.

>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>
>> If you get a chance, read through this and make sure the text
>> sounds ok (feel free to clean the text up as necessary).
>>
>> The application is due by 3 pm EST. So I hope to have the
>> application ready by 2ish. I'll move onto the application  
itself now.

>>
>> -- Josh
>>
>> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>
>>> Jeff is going to take the first pass at the application.
>>>
>>> I am going to go through the Idea page on the wiki and polish  
a bit:

>>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>>
>>> I'll let folks know when I'm done, and we can start iterating on
>>> drafts.
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>>
 I've created a quick-n-dirty hg to collaborate on the GSOC
 application.  There's a web form to fill out to apply, so let's
 work on a .txt file in the hg to get it right.

 We have until 3pm US Eastern time tomorrow to submit.  Here's
 the HG:

ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

 I've put the PDF there for now; I'll kruft up a quick .txt
 shortly and push it there as well.

 --
 Jeff Squyres
 Cisco Systems

 ___
 mtt-devel mailing list
 mtt-de...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Jeff Squyres]

Awesome; many thanks for carrying the baton over the finish line, Josh!

On Mar 13, 2009, at 2:56 PM, Josh Hursey wrote:


The application has been submitted. We find out on March 18 (3 pm) if
we have been accepted. Link to timeline below:
   http://socghop.appspot.com/document/show/program/google/gsoc2009/
timeline

Cheers,
Josh

On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:

> I just pushed a final draft to the repository. I'll probably plan
> on submitting at 2:30/2:45. Let me know if you have any edits
> before then either through email or IM.
>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>
>> I finished a first pass at cleaning up the Ideas page on the Wiki.
>> All of the ideas were preserved, just some rewording and  
formatting.

>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>
>> If you get a chance, read through this and make sure the text
>> sounds ok (feel free to clean the text up as necessary).
>>
>> The application is due by 3 pm EST. So I hope to have the
>> application ready by 2ish. I'll move onto the application itself  
now.

>>
>> -- Josh
>>
>> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>
>>> Jeff is going to take the first pass at the application.
>>>
>>> I am going to go through the Idea page on the wiki and polish a  
bit:

>>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>>
>>> I'll let folks know when I'm done, and we can start iterating on
>>> drafts.
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>>
 I've created a quick-n-dirty hg to collaborate on the GSOC
 application.  There's a web form to fill out to apply, so let's
 work on a .txt file in the hg to get it right.

 We have until 3pm US Eastern time tomorrow to submit.  Here's
 the HG:

ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

 I've put the PDF there for now; I'll kruft up a quick .txt
 shortly and push it there as well.

 --
 Jeff Squyres
 Cisco Systems

 ___
 mtt-devel mailing list
 mtt-de...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Jeff Squyres]

You have to "module load osl merurial" in your shell startup files  
somewhere for hg to work on milliways.


On Mar 13, 2009, at 3:15 PM, Ethan Mallove wrote:


On Fri, Mar/13/2009 02:19:24PM, Josh Hursey wrote:
> I just pushed a final draft to the repository. I'll probably plan on
> submitting at 2:30/2:45. Let me know if you have any edits before  
then

> either through email or IM.

Where's the repo? I'm looking at the .txt file in ~jsquyres/hg/gsoc,
but it looks incomplete. Does milliways have "hg" somewhere? (I'm
trying to find the parent repo using "hg out".)

-Ethan

>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>
>> I finished a first pass at cleaning up the Ideas page on the  
Wiki. All of

>> the ideas were preserved, just some rewording and formatting.
>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>
>> If you get a chance, read through this and make sure the text  
sounds ok

>> (feel free to clean the text up as necessary).
>>
>> The application is due by 3 pm EST. So I hope to have the  
application

>> ready by 2ish. I'll move onto the application itself now.
>>
>> -- Josh
>>
>> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>
>>> Jeff is going to take the first pass at the application.
>>>
>>> I am going to go through the Idea page on the wiki and polish a  
bit:

>>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>>
>>> I'll let folks know when I'm done, and we can start iterating on  
drafts.

>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>>
 I've created a quick-n-dirty hg to collaborate on the GSOC  
application.
 There's a web form to fill out to apply, so let's work on  
a .txt file in

 the hg to get it right.

 We have until 3pm US Eastern time tomorrow to submit.  Here's  
the HG:


ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

 I've put the PDF there for now; I'll kruft up a quick .txt  
shortly and

 push it there as well.

 --
 Jeff Squyres
 Cisco Systems

 ___
 mtt-devel mailing list
 mtt-de...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel



--
Jeff Squyres
Cisco Systems

Re: [MTT devel] GSOC application

[Ethan Mallove]

On Fri, Mar/13/2009 02:19:24PM, Josh Hursey wrote:
> I just pushed a final draft to the repository. I'll probably plan on 
> submitting at 2:30/2:45. Let me know if you have any edits before then 
> either through email or IM.

Where's the repo? I'm looking at the .txt file in ~jsquyres/hg/gsoc,
but it looks incomplete. Does milliways have "hg" somewhere? (I'm
trying to find the parent repo using "hg out".)

-Ethan

>
> Cheers,
> Josh
>
> On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:
>
>> I finished a first pass at cleaning up the Ideas page on the Wiki. All of 
>> the ideas were preserved, just some rewording and formatting.
>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>
>> If you get a chance, read through this and make sure the text sounds ok 
>> (feel free to clean the text up as necessary).
>>
>> The application is due by 3 pm EST. So I hope to have the application 
>> ready by 2ish. I'll move onto the application itself now.
>>
>> -- Josh
>>
>> On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:
>>
>>> Jeff is going to take the first pass at the application.
>>>
>>> I am going to go through the Idea page on the wiki and polish a bit:
>>>   https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas
>>>
>>> I'll let folks know when I'm done, and we can start iterating on drafts.
>>>
>>> Cheers,
>>> Josh
>>>
>>> On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:
>>>
 I've created a quick-n-dirty hg to collaborate on the GSOC application.  
 There's a web form to fill out to apply, so let's work on a .txt file in 
 the hg to get it right.

 We have until 3pm US Eastern time tomorrow to submit.  Here's the HG:

ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

 I've put the PDF there for now; I'll kruft up a quick .txt shortly and 
 push it there as well.

 -- 
 Jeff Squyres
 Cisco Systems

 ___
 mtt-devel mailing list
 mtt-de...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>>
>>> ___
>>> mtt-devel mailing list
>>> mtt-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>>
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Josh Hursey]

The application has been submitted. We find out on March 18 (3 pm) if  
we have been accepted. Link to timeline below:
  http://socghop.appspot.com/document/show/program/google/gsoc2009/ 
timeline


Cheers,
Josh

On Mar 13, 2009, at 2:19 PM, Josh Hursey wrote:

I just pushed a final draft to the repository. I'll probably plan  
on submitting at 2:30/2:45. Let me know if you have any edits  
before then either through email or IM.


Cheers,
Josh

On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:

I finished a first pass at cleaning up the Ideas page on the Wiki.  
All of the ideas were preserved, just some rewording and formatting.

  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

If you get a chance, read through this and make sure the text  
sounds ok (feel free to clean the text up as necessary).


The application is due by 3 pm EST. So I hope to have the  
application ready by 2ish. I'll move onto the application itself now.


-- Josh

On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:


Jeff is going to take the first pass at the application.

I am going to go through the Idea page on the wiki and polish a bit:
  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

I'll let folks know when I'm done, and we can start iterating on  
drafts.


Cheers,
Josh

On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:

I've created a quick-n-dirty hg to collaborate on the GSOC  
application.  There's a web form to fill out to apply, so let's  
work on a .txt file in the hg to get it right.


We have until 3pm US Eastern time tomorrow to submit.  Here's  
the HG:


   ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

I've put the PDF there for now; I'll kruft up a quick .txt  
shortly and push it there as well.


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Josh Hursey]

I just pushed a final draft to the repository. I'll probably plan on  
submitting at 2:30/2:45. Let me know if you have any edits before  
then either through email or IM.


Cheers,
Josh

On Mar 13, 2009, at 12:11 PM, Josh Hursey wrote:

I finished a first pass at cleaning up the Ideas page on the Wiki.  
All of the ideas were preserved, just some rewording and formatting.

  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

If you get a chance, read through this and make sure the text  
sounds ok (feel free to clean the text up as necessary).


The application is due by 3 pm EST. So I hope to have the  
application ready by 2ish. I'll move onto the application itself now.


-- Josh

On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:


Jeff is going to take the first pass at the application.

I am going to go through the Idea page on the wiki and polish a bit:
  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

I'll let folks know when I'm done, and we can start iterating on  
drafts.


Cheers,
Josh

On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:

I've created a quick-n-dirty hg to collaborate on the GSOC  
application.  There's a web form to fill out to apply, so let's  
work on a .txt file in the hg to get it right.


We have until 3pm US Eastern time tomorrow to submit.  Here's the  
HG:


   ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

I've put the PDF there for now; I'll kruft up a quick .txt  
shortly and push it there as well.


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Josh Hursey]

I finished a first pass at cleaning up the Ideas page on the Wiki.  
All of the ideas were preserved, just some rewording and formatting.

  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

If you get a chance, read through this and make sure the text sounds  
ok (feel free to clean the text up as necessary).


The application is due by 3 pm EST. So I hope to have the application  
ready by 2ish. I'll move onto the application itself now.


-- Josh

On Mar 12, 2009, at 4:43 PM, Josh Hursey wrote:


Jeff is going to take the first pass at the application.

I am going to go through the Idea page on the wiki and polish a bit:
  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

I'll let folks know when I'm done, and we can start iterating on  
drafts.


Cheers,
Josh

On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:

I've created a quick-n-dirty hg to collaborate on the GSOC  
application.  There's a web form to fill out to apply, so let's  
work on a .txt file in the hg to get it right.


We have until 3pm US Eastern time tomorrow to submit.  Here's the HG:

   ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

I've put the PDF there for now; I'll kruft up a quick .txt shortly  
and push it there as well.


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

Re: [MTT devel] GSOC application

[Josh Hursey]

Jeff is going to take the first pass at the application.

I am going to go through the Idea page on the wiki and polish a bit:
  https://svn.open-mpi.org/trac/mtt/wiki/MttNewFeaturesIdeas

I'll let folks know when I'm done, and we can start iterating on drafts.

Cheers,
Josh

On Mar 12, 2009, at 4:08 PM, Jeff Squyres wrote:

I've created a quick-n-dirty hg to collaborate on the GSOC  
application.  There's a web form to fill out to apply, so let's work  
on a .txt file in the hg to get it right.


We have until 3pm US Eastern time tomorrow to submit.  Here's the HG:

   ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

I've put the PDF there for now; I'll kruft up a quick .txt shortly  
and push it there as well.


--
Jeff Squyres
Cisco Systems

___
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel

[MTT devel] GSOC application

[Jeff Squyres]

I've created a quick-n-dirty hg to collaborate on the GSOC  
application.  There's a web form to fill out to apply, so let's work  
on a .txt file in the hg to get it right.


We have until 3pm US Eastern time tomorrow to submit.  Here's the HG:

ssh://www.open-mpi.org/~jsquyres/hg/gsoc/

I've put the PDF there for now; I'll kruft up a quick .txt shortly and  
push it there as well.


--
Jeff Squyres
Cisco Systems