Thanks for your feedback, Don! I'm glad to see we already have someone
helping us to find all the holes in the new API :-)
Excerpts from Don Zickus's message of 2013-03-29 02:02:47 +1000:
I have been enjoying the ease to code against the new Beaker API. The
GET, POST, PUSH stuff keeps things really simple. But during my testing I
noticed a few quirks that Bill P. suggested I email you about for your
- When I POST/PUT to a url, if the url has an extra '/' in the path, like
the command gets rejected. Not sure if that is an http thing or a server
thing. Not to much of a problem, just forces me to clean up my code
(which is good!). Just thought I would mention it.
Hmm I guess Flask isn't normalizing slashes for us, which is fair
enough. In HTTP those are two different URLs (//status and /status) even
though most web servers would then map them to the same filesystem path.
We could make beaker-proxy could do the normalization pretty easily.
- when I PUT a zero length file to the server, it fails with a 400
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
- Because the server does not have a mechanism to 'push' and
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
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.
If you got a 500 response that is definitely a bug regardless. Do you
have a stack trace from /var/log/beaker/server-errors.log for it? Or if
it was on beaker-devel, can you tell me roughly the timestamp and I will
look in the logs?
Actually I'm guessing it was because you were trying to record a result
against a finished task. I never considered that possibility originally.
It should probably give a 409 response instead. I will think about it
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.