[PATCH] schedule noarch tests on machines with 'noarch' autotest label

[Kamil Paral]

Please review:

https://fedorahosted.org/reviewboard/r/244/

[Josef Skladanka]

Reviewed, can be shipped IMHO.

BTW: reviewboard ends with HTTP 500 error code after login, what is the best place to report it?

----- Original Message -----
> From: "Kamil Paral" 
> To: "AutoQA development" 
> Sent: Monday, December 5, 2011 11:22:24 AM
> Subject: [PATCH] schedule noarch tests on machines with 'noarch' autotest label
>
> Please review:
>
> https://fedorahosted.org/reviewboard/r/244/
> _______________________________________________
> autoqa-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/autoqa-devel

[Kamil Paral]

> Reviewed, can be shipped IMHO.
>
> BTW: reviewboard ends with HTTP 500 error code after login, what is
> the best place to report it?

I guess it might be relevant to the recent invalidation of FAS passwords :-) Let's bug RB maintainers about it. Any idea who that is?

[Tim Flink]

On Tue, 06 Dec 2011 07:05:33 -0500 (EST)
Kamil Paral  wrote:
> > Reviewed, can be shipped IMHO.
> >
> > BTW: reviewboard ends with HTTP 500 error code after login, what is
> > the best place to report it?
>
> I guess it might be relevant to the recent invalidation of FAS
> passwords :-) Let's bug RB maintainers about it. Any idea who that
> is?

Pinged #fedora-admin and filed a ticket with fedora infra [1]. Will
review once reviewboard is working again.

Tim

[1] https://fedorahosted.org/fedora-infrastructure/ticket/3050

[Kamil Paral]

> Pinged #fedora-admin and filed a ticket with fedora infra [1]. Will
> review once reviewboard is working again.
>
> Tim
>
> [1] https://fedorahosted.org/fedora-infrastructure/ticket/3050

RB fixed.

[James Laska]

On Tue, 2011-12-06 at 07:05 -0500, Kamil Paral wrote:
> > Reviewed, can be shipped IMHO.
> >
> > BTW: reviewboard ends with HTTP 500 error code after login, what is
> > the best place to report it?
>
> I guess it might be relevant to the recent invalidation of FAS passwords :-) Let's bug RB maintainers about it. Any idea who that is?

Instead of adding a new label to all machines, it would be handy if
atest supported the wildcard completely.  For example...

The following atest command accepts a wildcard ...
$ atest host list -b "*"

While job creation doesn't fully support the wildcard ...
$ atest job create -g -m "*" ...

Operation create_job failed:
    ValidationError: {'meta_hosts': 'Label "" not found'}
Traceback (most recent call last):
  File "/usr/share/autotest/frontend/afe/json_rpc/serviceHandler.py",
line 96, in dispatchRequest
    results['result'] = self.invokeServiceEndpoint(meth, args)
  File "/usr/share/autotest/frontend/afe/json_rpc/serviceHandler.py",
line 134, in invokeServiceEndpoint
    return meth(*args)
  File "/usr/share/autotest/frontend/afe/rpc_handler.py", line 120, in
new_fn
    return f(*args, **keyword_args)
  File "/usr/share/autotest/frontend/afe/rpc_interface.py", line 527, in
create_job
    **rpc_utils.get_create_job_common_args(locals()))
  File "/usr/share/autotest/frontend/afe/rpc_utils.py", line 710, in
create_job_common
    {'meta_hosts' : 'Label "%s" not found' % label_name})
ValidationError: {'meta_hosts': 'Label "" not found'}

It's been working for our "noarch" style tests using a wildcard of
"*x86_64".  But having just a splat, results in the above traceback.

Not having fully investigated 'atest job create', it seems like this is
a bug worth fixing.  Either rpc_utils.py create_job_common() (or it's
callers) isn't properly handling a wildcard label.  If that worked,
noarch job scheduling might require fewer changes on our end.

Thanks,
James

[Kamil Paral]

> Not having fully investigated 'atest job create', it seems like this
> is
> a bug worth fixing.  Either rpc_utils.py create_job_common() (or it's
> callers) isn't properly handling a wildcard label.  If that worked,
> noarch job scheduling might require fewer changes on our end.
>
> Thanks,
> James

I added your comment to the relevant ticket:

https://github.com/autotest/autotest/issues/12#issuecomment-3034640

Thanks,
Kamil

[Tim Flink]

On Tue, 06 Dec 2011 08:37:54 -0500
James Laska  wrote:

<snip>
> Not having fully investigated 'atest job create', it seems like this
> is a bug worth fixing.  Either rpc_utils.py create_job_common() (or
> it's callers) isn't properly handling a wildcard label.  If that
> worked, noarch job scheduling might require fewer changes on our end.

I agree with James, I don't have any huge issues with the code but it
does sound like a change to atest would be a better solution (if
approved, accepted etc.).

I see that Kamil has been talking with lmr on the github issue [1] - do
we want to try fixing this ourselves and submitting a patch or do we
just wait to see what the resolution is?

Tim

[1] https://github.com/autotest/autotest/issues/12

[Kamil Paral]

> I agree with James, I don't have any huge issues with the code but it
> does sound like a change to atest would be a better solution (if
> approved, accepted etc.).
>
> I see that Kamil has been talking with lmr on the github issue [1] -
> do
> we want to try fixing this ourselves and submitting a patch or do we
> just wait to see what the resolution is?

My patch is so simple that I decided to act immediately no matter what the final resolution is - it will bring us performance increase for almost no cost (just putting the 'noarch' label on all machines).

If Lucas decides to fix it and it ends up in the next version of autotest - great, we can get rid of the extra label. If he doesn't fix it and someone from our team spends the time on writing that patch - ok, same approach. If that issue is rejected, well, I see bigger problems all around, this is just an inconvenience, I would live with that.

Any of those 3 scenarios doesn't seem to impact the included patch. Or do they?

[Kamil Paral]

> Please review:
>
> https://fedorahosted.org/reviewboard/r/244/

Pushed as d99f379.

Amended documentation here: https://fedoraproject.org/wiki/Managing_autotest_labels

Please make sure you define 'noarch' label and add it to all your local test clients, otherwise you'll see errors about a missing label or your noarch jobs will be queued indefinitely.

We have to include this instruction also in 0.8 release notes.