-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release used port by crc-daemon when stopping VM #4182
Comments
Please note that the ports are 'unexposed' when StopLine 11 in 813c80a
DeleteLine 25 in 813c80a
this sounds like an inconsistency. But to go on further about my reasoning:
This argument can also be reasoned the other way around. First, a 'user is always in control', and decides to stop the cluster. He can therefore expect that all resources are reclaimed and available. Especially for use with other processes. He would not expect this port to still be open, as CRC is not actively using it. The time between a start and stop can be just a few seconds, or even more than a few days. Would it be OK to keep this port claimed with the argument: "it might not behave as user expect". Honestly, from a mental model, a 'stop' would free resources and this is what a user would expect. An error on a successive start that would inform the user that might not be the case is more likely to be as expected and in line with "provide feedback to the user". Keeping the port claimed until a |
In my opinion, it would be better to release the ports on stop (and even, to release the port every time the VM goes from running to not running state), and this would make the behaviour more consistent between "vm is not created -> start" and "vm is created but stopped -> start". |
I can do this |
fixed in #4217 |
As of now we don't release the ports when
crc stop
is performed and ports are still associated withcrc-daemon
process. If a user want to consume those port he/she will not able to. Only downside I see if we allow to the user to consume those port and then user try start again the cluster from stopped state, it might not behave as user expectation (because port is used by other process).The text was updated successfully, but these errors were encountered: