Skip to content
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

Closed
praveenkumar opened this issue May 28, 2024 · 4 comments
Closed

Release used port by crc-daemon when stopping VM #4182

praveenkumar opened this issue May 28, 2024 · 4 comments
Assignees
Labels

Comments

@praveenkumar
Copy link
Member

As of now we don't release the ports when crc stop is performed and ports are still associated with crc-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).

@gbraad gbraad changed the title Release used port by crc-daemon when cluster in stopped state Release used port by crc-daemon when stopping VM May 28, 2024
@gbraad
Copy link
Contributor

gbraad commented May 28, 2024

Please note that the ports are 'unexposed' when delete is called, but not when stop is called for a VM.

Stop

func (client *client) Stop() (state.State, error) {

Delete

if err := unexposePorts(); err != nil {

this sounds like an inconsistency.

But to go on further about my reasoning:

it might not behave as user expectation (because port is used by other process).

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 crc cleanup is performed indicates an issue with the state of the daemon.

@gbraad gbraad added kind/bug Something isn't working points/1 priority/major labels May 29, 2024
@cfergeau
Copy link
Contributor

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".

@vyasgun
Copy link
Contributor

vyasgun commented May 29, 2024

I can do this
/assign

@anjannath
Copy link
Member

fixed in #4217

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants