[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