Sorry for the very belated reply, Don!
Excerpts from Don Zickus's message of 2013-04-02 23:53:56 +1000:
On Tue, Apr 02, 2013 at 06:07:15PM +1000, Dan Callaghan wrote:
> Excerpts from Don Zickus's message of 2013-03-29 02:02:47 +1000:
> > - when I PUT a zero length file to the server, it fails with a 400
> > code.
> > Now I should be filtering those (and will now). But it did take me an
> > hour before I realized that of my list of files, the rejected ones were of
> > zero length. Again could be on purpose, not sure.
>
> This definitely seems like a bug, I will investigate more this week.
> There is no reason why we should reject zero-length log files.
>
> Were you passing a Content-Range header? Do you happen to know what was
> in the response body from beaker-proxy (it should have an error
> message)?
Originally I wasn't, but now I implemented uploading in chunks, which uses
it. It doesn't matter, putting zeros for Content-Range and Content-Length
produces the same thing. So using urllib2.urlopen(), I have the following
exception handler:
except urllib2.HTTPError as e:
elif e.code == 400 and use_put:
log.error("Error(%s) failed to upload file %s" % (e.code, dest))
print "e is %s" %e
...
e is HTTP Error 400: BAD REQUEST
Another user has just reported this as a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=961300
It should be an easy fix on the lab controller side.
> > - Because the server does not have a mechanism to
'push' and abort the
> > client (other than power off), the client could still be running and
> > trying to pushing results back to the server.
> >
> > a POST of a task_result gave me an 'Internal Server Error 500'.
Will
> > that be the expected response? I can trap for that and abort the client.
> >
> > PUT of logs is still allowed even though the task aborted on the server
> > side. Bill thought that should be fixed. Though I am not sure what the
> > expectations are.
>
> Hmmm I think beah behaves the same way here. That is, it keeps on
> running happily even after the recipe has been cancelled, because there
> is nothing to stop it (until Beaker eventually pulls the plug). It's not
> necessarily a bad thing. But it might make sense to have some way for
> Beaker to tell the harness to stop running. I will think about it.
I was thinking a couple of things. Currently, I can maliciously upload
logs to a cancelled job and suck up disk space. Probably bad.
Yes I agree, that was an oversight really. Bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=962253
The other, my code can easily trap for a specific exception which
would indicate the recipe is done. I can then self abort. Right now
I use ISE 500 (which probably isn't the best). Up to you.
It should definitely be 409. Bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=962254
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.