Uh oh!
There was an error while loading. Please reload this page.
pod: Improve pod create performances - #484
Conversation
71f8940 to
918b7b1Compare| vmStartedCh := make(chan error) | ||
| const timeout = time.Duration(10) * time.Second | ||
| go p.hypervisor.waitPod(vmStartedCh) |
There was a problem hiding this comment.
Can we simply make waitPod blocking and pass it a timeout instead?
There was a problem hiding this comment.
Sure I can do that. The reason I have chosen such an implementation is to avoid the duplication of timeout handling for every hypervisor implementation.
| q.Logger().WithError(err).Warn("Failed to connect to QEMU instance, retrying...") | ||
| time.Sleep(time.Duration(50) * time.Millisecond) | ||
| } |
There was a problem hiding this comment.
This potentially is an infinite loop. By giving waitPod a timeout, you could implement a non infinte loop here based on the timeout argument.
There was a problem hiding this comment.
Yes I agree, but I thought that every hypervisor implementation will have to implement the same mechanism which is duplication. I know this could be an infinite loop but when the main process returns, this go routine is gonna be terminated.
| break | ||
| } | ||
| q.Logger().WithError(err).Warn("Failed to connect to QEMU instance, retrying...") |
There was a problem hiding this comment.
I would not print a new log entry every 50ms, but print one if we timeout instead.
sboeuf
commented
Nov 14, 2017
@sameo I am gonna make the changes ;) |
918b7b1 to
2f3541cCompareLGTM |
sboeuf
commented
Nov 14, 2017
@sameo comments addressed ! |
In order to optimize pod creation, this patch does not wait for the VM after it has been started. Instead, it will wait for it during the "start" stage. This will allow our VM to be started while the caller could potentially do other things between create and start. Globally, this improves the boot time of our containers. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2f3541c to
b20ba87Compare
pod: Improve pod create performances
In order to optimize pod creation, this patch does not wait for the
VM after it has been started. Instead, it will wait for it during the
"start" stage. This will allow our VM to be started while the caller
could potentially do other things between create and start. Globally,
this improves the boot time of our containers.