search

vlead / ovpl

ADS - Automated Deployment Service
MIT License
0 stars 22 forks source link

OVPL controller timeout for large sized repo #8

Open jayanthsagar opened 10 years ago

jayanthsagar commented 10 years ago

When OVPL is trying to release a lab of 1+ GB sized repositories the controller throws back "server is taking too long to respond", but OVPL is cloning the repo in background, if there is no network issues, the repo gets cloned and lab gets deployed successfully on a container but the developer doesn't know the details regarding the status of the lab.

travula commented 9 years ago

We should use web sockets to display to enable communication both ways. (server - client)

ecthiender commented 9 years ago

This would not solve the issue right. The issue is when ADS is cloning a repo and the repo is too large(~>1GB), it will take a lot of time for it to clone and in the meantime ADS times out and as a consequence, the lab installation fails.

Even if we have websockets for two way communication (so that the server can push the logs to the client), it is not going to solve this issue. We have to handle, in ADS, cloning of large repo, or we have threshold on the repo size. I think the latter is a better idea. I think it doesn't make sense to have source code repositories in order of GBs. I'm sure if we think about it, we can come up with lot many implications of having large repo sizes.

On Fri, Apr 17, 2015 at 12:08 PM, travula notifications@github.com wrote:

We should use web sockets to display to enable communication both ways. (server - client)

— Reply to this email directly or view it on GitHub https://github.com/vlead/ovpl/issues/8#issuecomment-93910856.

ecthiender commented 9 years ago

Thinking about it more, maybe having websocket logs solve this issue, the browser won't wait on a traditional HTTP method to return (in which it usually times out after ~10 mins). There would be a websocket connection which would keep updating the client(browser) about the current happenings.

Hence the user might actually see that clone is taking such amount of time. Having websockets based progress updation might solve this issue.