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 <local folder with
open-mpi-mtt>/
2. change version on
https://appengine.google.com/deployment?&app_id=open-mpi-mtt&version_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
__________ 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.esetnod32.ru
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4913 (20100303) __________
The message was checked by ESET NOD32 Antivirus.
http://www.esetnod32.ru
