[Beaker-devel] New Beaker API quirks
Dan Callaghan
dcallagh at redhat.com
Tue Apr 2 08:07:15 UTC 2013
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:
> Hi Dan,
>
> 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
> opinion.
>
> - When I POST/PUT to a url, if the url has an extra '/' in the path, like
>
> /recipes/(recipe_id)/tasks/(task_id)//status
>
> 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 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)?
> - 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.
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
some more.
--
Dan Callaghan <dcallagh at redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/beaker-devel/attachments/20130402/eea67a21/attachment.sig>
More information about the Beaker-devel
mailing list