Re: [MTT devel] MTToGDS
Ok. I'll try to look at this as well - but no promises about when I can do so... -jms Sent from my PDA. No type good. From: Igor Ivanov <igor.iva...@itseez.com> To: Igor Ivanov <igor.iva...@itseez.com> Cc: b...@argus-cv.com <b...@argus-cv.com>; Igor Ivanov <igor.iva...@argus-cv.com>; Development list for the MPI Testing Tool <mtt-de...@open-mpi.org>; mtt-devel-boun...@open-mpi.org <mtt-devel-boun...@open-mpi.org>; Mike Dubman <mi...@voltaire.com>; Jeff Squyres (jsquyres) Sent: Thu Mar 04 01:31:16 2010 Subject: Re: [MTT devel] MTToGDS Igor Ivanov wrote: I considered possibility to use cookie when issue was found out. But looking google documentation I could not understand if it solved this issue. So it require additional investigation that I do not have now. I will look in this way closer but current quick solutions were suggested in mail. Now we have information about issue and know ways to workaround them. Igor Jeff Squyres wrote: Yoinks. Alternatively, doesn't a Google login return a cookie of some flavor that is valid for a long period of time (somewhere between 1 day and 2 weeks)? Can't we keep/cache that cookie down in the MTT client and use it for subsequent data submissions until the cookie expires and we have to login again? On Feb 27, 2010, at 8:30 AM, Igor Ivanov wrote: Description: Issue arises during submitting data frequently. We can get failure during data submitting with authentication error. Reason: Google allows a failure response on The ClientLogin authorization process with a CAPTCHA challenge means that Google has decided, for whatever reason, that additional security measures should be taken. This response is accompanied by a CAPTCHA image URL and a token representing the specific CAPTCHA challenge. I do not see way to organize customer input in this case. Detail information can be found at: http://code.google.com/intl/en-EN/apis/accounts/docs/AuthForInstalledApps.html Possible solutions: 1. catch error condition on server side and return status 503: 'Service Unavailable'; In this case client can organize processing of this failure (it is possible that sleeping for some time could help) 2. catch error condition on server side and accept authentication by correct username only w/o real verification; 3. rollback to previous scheme; Igor Igor Ivanov wrote: Hi Jeff, I am sending patch that enable google account approach to submit data to MTT GDS. It also has the fix to a bug in displaying table as respond to bquery.pl --view (It has not been committed yet to MTT trunk). As for question relating "how does one develop ..." that source information can be found at following location as: http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc. In case you make a resolve to accept patch I am sending next steps should be done: 1. update application on server side using instruction in VBench_GDS_Setup.doc (topic 4 "Installation") example: appcfg.py update / 2. change version on https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607 from 1 to 2 (make default) note: after this operation all users that attempt to submit data using previous scheme of authentication will get failure respond. 3. go to open-mpi-mtt and add new users with google account Regards, Igor Jeff Squyres wrote: Great -- many thanks!
Re: [MTT devel] MTToGDS
Fair enough (the appspot is quit limited to admin). But the next time we edit it, if we could add some kind of printf about "you are signed in with a google account that does not have access to this portion of the app spot; please re-login as an authorized user" or something simple like that, that would be great. That's all I was asking about - not developing more capabilities of the admin side of the appspot. -jms Sent from my PDA. No type good. From: Igor Ivanov <igor.iva...@itseez.com> To: Igor Ivanov <igor.iva...@itseez.com> Cc: b...@argus-cv.com <b...@argus-cv.com>; Igor Ivanov <igor.iva...@argus-cv.com>; Development list for the MPI Testing Tool <mtt-de...@open-mpi.org>; yift...@voltaire.com <yift...@voltaire.com>; Mike Dubman <mi...@voltaire.com>; Jeff Squyres (jsquyres) Sent: Thu Mar 04 01:30:56 2010 Subject: Re: [MTT devel] MTToGDS Igor Ivanov wrote: Hi Jeff, Look at my comments below. Note: be aware that my mail has been changed to itseez.com domain. Igor Jeff Squyres wrote: On Feb 16, 2010, at 10:19 AM, Igor Ivanov wrote: I am sending patch that enable google account approach to submit data to MTT GDS. It also has the fix to a bug in displaying table as respond to bquery.pl --view (It has not been committed yet to MTT trunk). Thanks guys! And sorry for my long lack of response - I was working in a window of availability for MTT stuff before, and then that window closed and I got sucked into other high priority things. I have another small window of availability for MTT now... It looks like Mike D. committed this stuff to SVN already, right? If so, great! As for question relating "how does one develop ..." that source information can be found at following location as: http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc. Ok, I'll dig into that. One thing that is quite confusing is the sign in to http://open-mpi-mtt.appspot.com/. When you go there, you get a "Sign in or register" link. You click that and get to a Google Accounts login. I used openmpi.ci...@gmail.com and its associated password, but then I'm bounced back to the "Sign in or register" link. Only when I login as open...@gmail.com do I actually get beyond the "Sign in or register" link. Does this mean that openmpi.ci...@gmail.com does not have login privlidges on the open-mpi-mtt appspot? If so, can we add a better error message than this? It's very confusing -- because you *are* apparently signing in to a google account properly, but then you just get the "Sign in or register" link again. [ii] As I mentioned in previous mails current form of web-site suits administrating purpose mostly (to fit full multiuser access it should be provided additional operations). So I knowingly limited admission for administrator only as "openmpi" to avoid additional questions in multiuser usage. In case you make a resolve to accept patch I am sending next steps should be done: 1. update application on server side using instruction in VBench_GDS_Setup.doc (topic 4 "Installation") example: appcfg.py update / 2. change version on https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607 from 1 to 2 (make default) note: after this operation all users that attempt to submit data using previous scheme of authentication will get failure respond. 3. go to open-mpi-mtt and add new users with google account It looks like this was all done already -- probably because I took so long to reply. Thanks! __ Information from ESET NOD32 Antivirus, version of virus signature database 4913 (20100303) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru __ Information from ESET NOD32 Antivirus, version of virus signature database 4913 (20100303) __ The message was checked by ESET NOD32 Antivirus. http://www.eset
Re: [MTT devel] MTToGDS
Yoinks. Alternatively, doesn't a Google login return a cookie of some flavor that is valid for a long period of time (somewhere between 1 day and 2 weeks)? Can't we keep/cache that cookie down in the MTT client and use it for subsequent data submissions until the cookie expires and we have to login again? On Feb 27, 2010, at 8:30 AM, Igor Ivanov wrote: > Description: > Issue arises during submitting data frequently. We can get failure during > data submitting with authentication error. > > Reason: > Google allows a failure response on The ClientLogin authorization process > with a CAPTCHA challenge means that Google has decided, for whatever reason, > that additional security measures should be taken. This response is > accompanied by a CAPTCHA image URL and a token representing the specific > CAPTCHA challenge. > I do not see way to organize customer input in this case. > > Detail information can be found at: > http://code.google.com/intl/en-EN/apis/accounts/docs/AuthForInstalledApps.html > > Possible solutions: > 1. catch error condition on server side and return status 503: 'Service > Unavailable'; > In this case client can organize processing of this failure (it is possible > that sleeping for some time could help) > 2. catch error condition on server side and accept authentication by correct > username only w/o real verification; > 3. rollback to previous scheme; > > > Igor > > Igor Ivanov wrote: >> Hi Jeff, >> >> I am sending patch that enable google account approach to submit data to MTT >> GDS. >> It also has the fix to a bug in displaying table as respond to bquery.pl >> --view (It has not been committed yet to MTT trunk). >> >> As for question relating "how does one develop ..." that source information >> can be found at following location as: >> http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc. >> In case you make a resolve to accept patch I am sending next steps should be >> done: >> >> 1. update application on server side using instruction in >> VBench_GDS_Setup.doc (topic 4 "Installation") >> example: appcfg.py update / >> 2. change version on >> https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607 >> from 1 to 2 (make default) >> note: after this operation all users that attempt to submit data using >> previous scheme of authentication will get failure respond. >> 3. go to open-mpi-mtt and add new users with google account >> >> >> Regards, >> Igor >> >> Jeff Squyres wrote: >>> Great -- many thanks! >>> >>> On Feb 12, 2010, at 12:32 PM, Igor Ivanov wrote: >>> >>> >>> Hi Jeff, I have done changes related google account support but not tested them well. I will try to send them on Monday. Regards, Igor Jeff Squyres wrote: > On Feb 10, 2010, at 9:09 AM, Igor Ivanov wrote: > > > > > >>> I took a swipe at doing this (totally not tested; how does one >>> develop/test this stuff?). I know just a tiny bit of python, but the >>> code was fairly readable. Please see the attached patch -- is it >>> anywhere close to correct? >>> >>> >>> >>> >>> >> [II] It seems close but you forget about bquery.pl that allows to add a >> new user and related handler (processes bquery.pl --admin) on >> gds/main.py at least. >> >> >> >> > Oh, yikes -- good catch. I'll look into that... > > How does one develop / test / debug / deploy changes to this stuff? > > > > > __ Information from ESET NOD32 Antivirus, version of virus signature database 4861 (20100212) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru >>> >>> >>> >>> >> >> >> __ Information from ESET NOD32 Antivirus, version of virus signature >> database 4871 (20100216) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.esetnod32.ru >> >> >> __ Information from ESET NOD32 Antivirus, version of virus signature >> database 4871 (20100216) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.esetnod32.ru >> >> ___ >> mtt-devel mailing list >> >> mtt-de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel >> >> >> >> >> __ Information from ESET NOD32 Antivirus, version of virus signature >> database 4871 (20100216) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> >> http://www.esetnod32.ru >> >> >> > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 4899 (20100226) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.esetnod32.ru -- Jeff Squyres
Re: [MTT devel] MTToGDS
Hi Jeff, It seems that one issue related google account auth method has been detected. Description: Issue arises during submitting data frequently. We can get failure during data submitting with authentication error. Reason: Google allows a failure response on The ClientLogin authorization process with a CAPTCHA challenge means that Google has decided, for whatever reason, that additional security measures should be taken. This response is accompanied by a CAPTCHA image URL and a token representing the specific CAPTCHA challenge. I do not see way to organize customer input in this case. Detail information can be found at: http://code.google.com/intl/en-EN/apis/accounts/docs/AuthForInstalledApps.html Possible solutions: 1. catch error condition on server side and return status 503: 'Service Unavailable'; In this case client can organize processing of this failure (it is possible that sleeping for some time could help) 2. catch error condition on server side and accept authentication by correct username only w/o real verification; 3. rollback to previous scheme; Igor Igor Ivanov wrote: Hi Jeff, I am sending patch that enable google account approach to submit data to MTT GDS. It also has the fix to a bug in displaying table as respond to bquery.pl --view (It has not been committed yet to MTT trunk). As for question relating "how does one develop ..." that source information can be found at following location as: http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc. In case you make a resolve to accept patch I am sending next steps should be done: 1. update application on server side using instruction in VBench_GDS_Setup.doc (topic 4 "Installation") example: appcfg.py update / 2. change version on https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607 from 1 to 2 (make default) note: after this operation all users that attempt to submit data using previous scheme of authentication will get failure respond. 3. go to open-mpi-mtt and add new users with google account Regards, Igor Jeff Squyres wrote: Great -- many thanks! On Feb 12, 2010, at 12:32 PM, Igor Ivanov wrote: Hi Jeff, I have done changes related google account support but not tested them well. I will try to send them on Monday. Regards, Igor Jeff Squyres wrote: On Feb 10, 2010, at 9:09 AM, Igor Ivanov wrote: I took a swipe at doing this (totally not tested; how does one develop/test this stuff?). I know just a tiny bit of python, but the code was fairly readable. Please see the attached patch -- is it anywhere close to correct? [II] It seems close but you forget about bquery.pl that allows to add a new user and related handler (processes bquery.pl --admin) on gds/main.py at least. Oh, yikes -- good catch. I'll look into that... How does one develop / test / debug / deploy changes to this stuff? __ Information from ESET NOD32 Antivirus, version of virus signature database 4861 (20100212) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru __ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru __ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru ___ mtt-devel mailing list mtt-de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel __ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru __ Information from ESET NOD32 Antivirus, version of virus signature database 4899 (20100226) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru
Re: [MTT devel] MTToGDS
Jeff Squyres wrote: On Feb 10, 2010, at 4:12 AM, Igor Ivanov wrote: Is it hard to redirect the appspot lookup to use google account names + passwords? [II] I believe that it is possible task. It could be done in two ways: set google account e-mail in mttdatabase_username key of ini-file 1) provide for filling User.username with google account e-mail and change code of User.check_password in file gds/auth/models.py to with google account verification code code example (I have not checked one): I took a swipe at doing this (totally not tested; how does one develop/test this stuff?). I know just a tiny bit of python, but the code was fairly readable. Please see the attached patch -- is it anywhere close to correct? [II] It seems close but you forget about bquery.pl that allows to add a new user and related handler (processes bquery.pl --admin) on gds/main.py at least. User.get_full_name() would still need to be re-done. How does one fetch Google account info like that? [II] May be you asked following http://code.google.com/appengine/docs/python/users/userclass.html Keep in mind performance difference between google account verification code and local verification! Yep -- am not worried about that. MTT data submits don't have to be super speedy. If a local verification takes (say) .01 second, and a google account verification takes 1 second (or even a few seconds), I don't think it'll matter. [II] We should take into account limitations and quotes (response etc) that are specific for google app: http://code.google.com/appengine/docs/python/runtime.html#Responses __ Information from ESET NOD32 Antivirus, version of virus signature database 4854 (20100210) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru
Re: [MTT devel] MTToGDS
Yes, it is more friendly way.
Jeff Squyres wrote:
On Feb 10, 2010, at 4:18 AM, Igor Ivanov wrote:
I believe that it is just a warning and you can use mtt w/o analyzer that allow get additional info from output.
True, it's just a warning. But it's (very) big and ugly. :-) Makes it quite difficult to read --verbose output and see if anything actually went wrong.
Is this patch correct? It checks to see if there is no analyze_module, and if so, just returns the form.
Index: lib/MTT/Reporter/MTTGDS.pm
===
--- lib/MTT/Reporter/MTTGDS.pm (revision 1346)
+++ lib/MTT/Reporter/MTTGDS.pm (working copy)
@@ -576,6 +576,11 @@
my $ini= $MTT::Globals::Internals->{ini};
my $module = $ini->val( "Test run: " . $section, "analyze_module" );
+
+# If there's no analyze module, then just return
+return $form
+if (!$module);
+
$module = "MTT::Test::Analyze::Performance::$module";
my $method = "PreReport";
my @args = ( $phase, $section, $report );
__ Information from ESET NOD32 Antivirus, version of virus signature database 4854 (20100210) __
The message was checked by ESET NOD32 Antivirus.
http://www.esetnod32.ru
Re: [MTT devel] MTToGDS
On Feb 10, 2010, at 4:18 AM, Igor Ivanov wrote:
> I believe that it is just a warning and you can use mtt w/o analyzer that
> allow get additional info from output.
True, it's just a warning. But it's (very) big and ugly. :-) Makes it quite
difficult to read --verbose output and see if anything actually went wrong.
Is this patch correct? It checks to see if there is no analyze_module, and if
so, just returns the form.
Index: lib/MTT/Reporter/MTTGDS.pm
===
--- lib/MTT/Reporter/MTTGDS.pm (revision 1346)
+++ lib/MTT/Reporter/MTTGDS.pm (working copy)
@@ -576,6 +576,11 @@
my $ini= $MTT::Globals::Internals->{ini};
my $module = $ini->val( "Test run: " . $section, "analyze_module" );
+
+# If there's no analyze module, then just return
+return $form
+if (!$module);
+
$module = "MTT::Test::Analyze::Performance::$module";
my $method = "PreReport";
my @args = ( $phase, $section, $report );
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [MTT devel] MTToGDS
On Feb 10, 2010, at 4:12 AM, Igor Ivanov wrote: >> Is it hard to redirect the appspot lookup to use google account names + >> passwords? >> > [II] I believe that it is possible task. It could be done in two ways: > set google account e-mail in mttdatabase_username key of ini-file > 1) provide for filling User.username with google account e-mail and change > code of User.check_password in file gds/auth/models.py to with google > account verification code > code example (I have not checked one): I took a swipe at doing this (totally not tested; how does one develop/test this stuff?). I know just a tiny bit of python, but the code was fairly readable. Please see the attached patch -- is it anywhere close to correct? User.get_full_name() would still need to be re-done. How does one fetch Google account info like that? > Keep in mind performance difference between google account verification code > and local verification! Yep -- am not worried about that. MTT data submits don't have to be super speedy. If a local verification takes (say) .01 second, and a google account verification takes 1 second (or even a few seconds), I don't think it'll matter. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ use-google-account.patch Description: Binary data
Re: [MTT devel] MTToGDS
On Feb 10, 2010, at 1:45 AM, Mike Dubman wrote:
> The GDS files use libyaml interfaces (there is no explictic 'use Syck'
> in the code). I think it is implicit dependancy of one of the perl
> modules or when you do "yum install libyaml perl-Yaml --> it brings syck
> as well)
It seems to be coming from bquery.pl (I didn't try breport.pl yet) -- if I
don't have YAML::Syck installed, perl complains that it can't find it in @INC.
Odd.
> > I'm testing bquery.pl -- unfortunately, I'm behind some
> > proxies in the Cisco lab environment. I'll see if I can add
> > proxy support...
>
> It works for us behind the proxy with HTTP_PROXY shell vars.
I committed some changes to bquery.pl last night for this. The issue is that
$ENV{http_proxy} is unfortunately overloaded by multiple different apps and
environments -- some require the value to be of the form:
proxy_host_name[:port]
Others (like LWP) require it to be of the form
scheme://proxy_host_name[:port]
In my environment, I use the former (with no scheme). So I added some code in
bquery.pl to check and see if there is no scheme at the beginning of
$ENV{http_proxy}. If there isn't, add the same scheme that is at the prefix of
the URL that we're submitting to.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [MTT devel] MTToGDS
I believe that it is just a warning and you can use mtt w/o analyzer that allow get additional info from output. Regards, Igor Jeff Squyres wrote: On Feb 9, 2010, at 5:34 PM, Jeff Squyres (jsquyres) wrote: 6. Could you send detail info about the issue (ini-file, mtt.log with verbose info and command line), we will look on that. Let me reproduce and simplify; I was using a fairly complex ini file... Oh, I see what happened -- I ran MTT manually on the command line and stepped through each of the phases manually, just to watch what was happening in each phase. Something like this mtt --file foo.ini --verbose --mpi-get mtt --file foo.ini --verbose --mpi-install mtt --file foo.ini --verbose --test-get mtt --file foo.ini --verbose --test-build mtt --file foo.ini --verbose --test-run If I run just a single mtt invocation, the submitting for mpi install and test build seems to work. However, there seems to be some built-in assumption that analyze::performance must be called...? I was just running the "trivial" suites and trying to submit that. Here's the --verbose output (I added the "GDS" verbose lines): ..lots of tests passing output Test: cxx_ring, np=16, variant=8: Passed Test: cxx_ring, np=16, variant=9: Passed Test: cxx_ring, np=16, variant=10: Passed Test: cxx_ring, np=16, variant=11: Passed Test: cxx_ring, np=16, variant=12: Passed ### Test progress: 8 of 8 section test executables complete. Moving on. Reporter MTTGDS: cached for later submit *** Run test phase complete *** Reporter finalizing Submitted MPI Install to GDS Submitted Test Build to GDS *** WARNING: Could not load module MTT::Test::Analyze::Performance::: Can't locate MTT/Test/Analyze/Performance/.pm in @INC (@INC contains: /home/jsquyres/svn/mtt/lib /usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.4/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.3/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.2/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.1/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.4/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.2/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.1/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at (eval 1089) line 3. ..and oodles more errors just like this Submitted Test Run to GDS *** Reporter finalized It looks like there is supposed to be some .pm file that I was supposed to have specified...? I'm not quite sure why, though -- performance analyzers shouldn't be necessary for all tests. We have oodles of correctness tests where performance isn't an issue, so that analysis is irrelevant. One further question -- the initial email from Michael said that both libYAML and Syck are necessary. Why both? yaml.org says that Syck is the "old" interface and libYAML is preferred these days. I'm testing bquery.pl -- unfortunately, I'm behind some proxies in the Cisco lab environment. I'll see if I can add proxy support... __ Information from ESET NOD32 Antivirus, version of virus signature database 4852 (20100209) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru
Re: [MTT devel] MTToGDS
On Feb 5, 2010, at 4:56 AM, Igor Ivanov wrote: > Thank you to start playing with one. I hope you find it is useful. > I am trying to answer questions you raised. Thanks! Sorry for the delay in my answering -- got caught up in other stuff... Ugh! > 1. Yes, you are correct. The implementation uses google account authorization > way to access web page only. Client applications use separate approach to > communicate with datastore. > It is difficult to say what way is better from my point of view. In both ways > we need to manage list of valid accounts to answer "is this username/password > combo valid?" (Google does not do this task instead of us) and send > username/password information from a client to application. Visible > preference could exist in case web usage that was not main goal. Gotcha. FWIW, I think it would be (slightly) easier if we don't have to manage users' passwords on the appspot. If the MTT client can just submit using a regular google account username+password, that would be one less thing to have to manage. I guess I'm a little burned out from our current MTT setup where people had to bug me to reset their passwords (in a local .htaccess file) whenever they lost/forgot them. :-) All things being equal, you're right, of course -- a) we still have to maintain a list of google accounts who are allowed to submit/access/whatever, b) we still have to ship off a username/password combo and ask if it's valid. But eliminating that password column from our data, IMHO, represents pushing off all account management to Google. Is it hard to redirect the appspot lookup to use google account names + passwords? > 2. Current implementation of datastore environment is oriented on client > usage way mostly and does not grant users rich web possibility. Existing web > form can be considered as instrument for an administrator now. Gotcha. Someday someone with lots of time can write a glitzy web 2.0 interface. ;-) > There is special command line utility that allows to communicate with > datastore as bquery.pl located at /src/client. It is able to do > query data from datastore and view different information on console using > extended (more close to sql) gql syntax that is implemented for users > comfort. More detail information can be got from document as > http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_bquery.doc > > For example: > to get information related mpi install following command line can be used > > $ ./bquery.pl --username= --password= > --server=http://.appspot.com > --view --gqls="select description, mpi_path from MpiInstallPhase where > duration=1" --format=txt > > description mpi_path > -- > Voltaire already installed MPI+OMA /opt/openmpi/1.3 > ... Nifty -- I'll go play with this... > 3. In case we can collect all needed information about cluster using > transparent way we should do it. ClusterInfo.pm is attempt to get info in one > place in clear manner. I ask because many of the assumptions in ClusterInfo.pm are not valid for my cluster. > 4. You are right it can be done. If you don't care, and since I'm the one making such an annoying request, I'll be happy to do the work for this one. :-) > 5. Results are cached to keep link information between "test build" ->"mpi > install"; "test run"->"test build" ->"mpi install" phases. Ah -- I see. In the SQL submitter, when we submit each phase, we get an ID back to use for the next linked phase (e.g., the mpi install submit returns an ID that is used with a corresponding test build submit, etc.). Is that not possible here? I.e., can a submit return an ID to be used with the next submit? I ask for two reasons: 1. When running a huge number of tests in MTT (like I do), it is useful to see the results start appearing in the database gradually over time rather than having to wait (potentially) many hours for all the results to appear at once. 2. I actually run OMPI testing in two phases at Cisco: a. (mpi get + mpi install + test get + test build) for ~25 different mpi install sections b. as each one of those finish, launch test run phases for each, with either ~10 or ~25 mpi details variants (depending on the specific mpi install) Specifically, I execute each of my test_run phases separately from all the other phases (because I have lots of them running in parallel for a given mpi install). Hence, the test run phase needs to be able to run long after all the other phase results were submitted. I believe IU and Sun do similar things (although our MTT setups are quite different from each other, I think we have all separated the get/install/get/build stuff from test runs). > 6. Could you send detail info about the issue (ini-file, mtt.log with verbose > info and command line), we will look on that. Let me reproduce and simplify; I was using a fairly complex ini file...
Re: [MTT devel] MTToGDS
Mike -- Many thanks! This rocks. I'm embarrassed to say that I broke Cisco's MTT a little while ago and haven't found the cycles yet to fix it. This is excellent motivation for me to a) fix my MTT runs, and b) start trying to submit to Google. Woo hoo! On Sep 29, 2009, at 3:21 PM, Mike Dubman wrote: Hello guys and gals, We have completed development and testing of Google DataStore support in MTT and are glad to submit it for community tests. New Files: The following new files were added to support GDS inside MTT: 1. client/bquery.pl Perl-based GDS client, provides basic DB querying/fetching capabilities. It creates resultset (files in YAML format) from user- provided sql-like query 2. client/breport.pl Perl-based report tool, creates excel reports from yaml files, generated by bquery.pl tool. 3. client/custom_launchers/ For brave only: custom launchers for non-standard HPC, mpi-based applications 4. lib/MTT/Reporter/MTTGDS.pm GDS Reporter, saves mtt results to GDS (see samples/gds-demo.ini for configuration examples) 5. lib/MTT/Utils/ClusterInfo.pm Helper library to gather node hw/sw configuration information which is saved in GDS together with tests results. 6. New TestResults analyzers for HPC applications: lib/MTT/test/Analyze/Performance/Fluent.pm lib/MTT/test/Analyze/Performance/HPCC.pm lib/MTT/test/Analyze/Performance/HPLGDS.pm lib/MTT/test/Analyze/Performance/OpenFoam.pm lib/MTT/test/Analyze/Performance/PamCrash.pm 7. samples/gds-demo.ini Example of howto configure GDS in MTT and run bquery/breport tools at the end of MTT session 8. server/gds/ GDS backend part, which is running at Google and providing Object to YAML, YAML to Object translation service as well as helper code for bquery.pl DB client. 9. docs/gds/ Various documentation Known Issues and Limitations: == * lib/MTT/Utils/ClusterInfo.pm uses "sudo" command to gather node`s hardware information. * When using client/custom_launchers/ to run tests, it is impossible to kill the test application when timeout reached. How to start using MTToGDS: == * Contact Jeff to provide you with GDS login/password which is needed for querying/saving to DB (http://open-mpi-mtt.appspot.com) * See samples/gds-demo.ini for configuration examples as well as for DB querying and reports generation. * Read Google GQL syntax documentation and use it with bquery.pl in order to query objects from GDB. * The following perl modules are required for all MTToGDS components: libYAML YAML::Syck YAML::XS for breport: GD::Graph Spreadsheet::WriteExcel You can install it on linux systems with yum as following: yum install perl-libyaml perl-YAML-Syck perl-YAML-XS perl-GD-Graph perl-Spreadsheet-WriteExcel Special Thanks to: == Igor Ivanov, Andrew Senin, Alexander Alekhin from Argus-Cv.com for they contribution in developing and testing of this feature! Regards Mike ___ mtt-devel mailing list mtt-de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel -- Jeff Squyres jsquy...@cisco.com
