graphics_SanAngeles doesn't need to log in

graphics_SanAngeles doesn't need to log in

sometimes, graphics_SanAngeles fails to log in to run.  But it doesn't need to in the first place.

BUG=chrome-os-partner:711
TEST=run it

Change-Id: I3803b62f7af74225b05ef6e017d35e2c444f7da5

[petkov, 2010-08-18 00:05:01]

In your testing, did you see the demo running on the netbook screen?

http://codereview.chromium.org/3137016/diff/1/2
File client/site_tests/graphics_SanAngeles/graphics_SanAngeles.py (right):

http://codereview.chromium.org/3137016/diff/1/2#newcode7
client/site_tests/graphics_SanAngeles/graphics_SanAngeles.py:7: from
autotest_lib.client.bin import site_login, test as bin_test
why import as bin_test? no other test is doing that, I think.

[jrbarnette, 2010-08-18 00:12:26]

If this test doesn't need to log in, then it shouldn't do so.
That said, I have to ask:  are you sure you're not just
masking a problem with login that needs to be debugged?

Put another way:  Why do you think that the San Angeles
test's occasional failure to log in is the fault of the test?

[Chris Masone, 2010-08-18 00:18:03]

On Tue, Aug 17, 2010 at 5:12 PM, <jrbarnette@chromium.org> wrote:

> If this test doesn't need to log in, then it shouldn't do so.
>

Yes, that's why I'm doing this.


> That said, I have to ask:  are you sure you're not just
> masking a problem with login that needs to be debugged?
>
> Put another way:  Why do you think that the San Angeles
> test's occasional failure to log in is the fault of the test?
>
> I'm not.  You're assuming I'm ignoring the problem, when actually I'm
trying to figure out what's going on in parallel.  That said...as you
say...this test has no need to log in, and so it shouldn't.

Put another way...why should login failures cause this test to fail?  They
shouldn't, and so I'm rightfully decoupling that dependency.


>
>
> http://codereview.chromium.org/3137016/show
>

[Chris Masone, 2010-08-18 00:41:31]

On 2010/08/18 00:18:03, Chris Masone wrote:
> On Tue, Aug 17, 2010 at 5:12 PM, <mailto:jrbarnette@chromium.org> wrote:
> 
> > If this test doesn't need to log in, then it shouldn't do so.
> >
> 
> Yes, that's why I'm doing this.
> 
> 
> > That said, I have to ask:  are you sure you're not just
> > masking a problem with login that needs to be debugged?
> >
> > Put another way:  Why do you think that the San Angeles
> > test's occasional failure to log in is the fault of the test?
> >
> > I'm not.  You're assuming I'm ignoring the problem, when actually I'm
> trying to figure out what's going on in parallel.  That said...as you
> say...this test has no need to log in, and so it shouldn't.
> 
> Put another way...why should login failures cause this test to fail?  They
> shouldn't, and so I'm rightfully decoupling that dependency.
> 
> 
> >
> >
> > http://codereview.chromium.org/3137016/show
> >
> 

So, if it doesn't log in at all, the WM won't map the window with the test
graphics in it.  Lovely.

Thus, i log in with the backdoor creds, to remove as much dependency on login
code as possible.

[jrbarnette, 2010-08-18 00:45:24]

On Aug 17, 2010, at 5:17 PM, Chris Masone wrote:

>
>
> On Tue, Aug 17, 2010 at 5:12 PM, <jrbarnette@chromium.org> wrote:
> If this test doesn't need to log in, then it shouldn't do so.
>
> Yes, that's why I'm doing this.
>
> That said, I have to ask:  are you sure you're not just
> masking a problem with login that needs to be debugged?
>
> Put another way:  Why do you think that the San Angeles
> test's occasional failure to log in is the fault of the test?
>
> I'm not.  You're assuming I'm ignoring the problem, when actually  
> I'm trying to figure out what's going on in parallel.  That  
> said...as you say...this test has no need to log in, and so it  
> shouldn't.
>

I almost said it before, so I'll say it now:  "I don't
understand it, but I want this change in the tree while
I debug it" is a perfectly good answer (thrilling, in
fact).  It's just that the thrill wasn't real to me
because I hadn't heard you say it.  :-)



> Put another way...why should login failures cause this test to  
> fail?  They shouldn't, and so I'm rightfully decoupling that  
> dependency.
>
>
>
> http://codereview.chromium.org/3137016/show
>

-- jrb

[Chris Masone, 2010-08-18 01:02:46]

On Tue, Aug 17, 2010 at 5:45 PM, Richard Barnette
<jrbarnette@chromium.org>wrote:

> On Aug 17, 2010, at 5:17 PM, Chris Masone wrote:
>
>
>>
>> On Tue, Aug 17, 2010 at 5:12 PM, <jrbarnette@chromium.org> wrote:
>> If this test doesn't need to log in, then it shouldn't do so.
>>
>> Yes, that's why I'm doing this.
>>
>> That said, I have to ask:  are you sure you're not just
>> masking a problem with login that needs to be debugged?
>>
>> Put another way:  Why do you think that the San Angeles
>> test's occasional failure to log in is the fault of the test?
>>
>> I'm not.  You're assuming I'm ignoring the problem, when actually I'm
>> trying to figure out what's going on in parallel.  That said...as you
>> say...this test has no need to log in, and so it shouldn't.
>>
>>
> I almost said it before, so I'll say it now:  "I don't
> understand it, but I want this change in the tree while
> I debug it" is a perfectly good answer (thrilling, in
> fact).  It's just that the thrill wasn't real to me
> because I hadn't heard you say it.  :-)
>
>  http://code.google.com/p/chromium-os/issues/detail?can=2&q=5223

There's been a known issue for weeks that could be causing all of these
issues.  It remains unclear to me why no one has been willing to touch it.


>
>
>  Put another way...why should login failures cause this test to fail?  They
>> shouldn't, and so I'm rightfully decoupling that dependency.
>>
>>
>>
>> http://codereview.chromium.org/3137016/show
>>
>>
> -- jrb
>
>

[petkov, 2010-08-18 04:52:09]

LGTM w/ a comment.

http://codereview.chromium.org/3137016/diff/7001/8005
File server/site_tests/suite_Nightly/control (right):

http://codereview.chromium.org/3137016/diff/7001/8005#newcode38
server/site_tests/suite_Nightly/control:38: ('graphics_SanAngeles', {'creds':
'$backdoor}),
missing a closing tick?