-
Notifications
You must be signed in to change notification settings - Fork 43
Conversation
71f8940
to
918b7b1
Compare
pod.go
Outdated
vmStartedCh := make(chan error) | ||
const timeout = time.Duration(10) * time.Second | ||
|
||
go p.hypervisor.waitPod(vmStartedCh) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we simply make waitPod
blocking and pass it a timeout instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
qemu.go
Outdated
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
qemu.go
Outdated
break | ||
} | ||
|
||
q.Logger().WithError(err).Warn("Failed to connect to QEMU instance, retrying...") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not print a new log entry every 50ms, but print one if we timeout instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change that.
@sameo I am gonna make the changes ;) |
918b7b1
to
2f3541c
Compare
@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 <[email protected]>
2f3541c
to
b20ba87
Compare
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.