search

crc-org / crc

CRC is a tool to help you run containers. It manages a local OpenShift 4.x cluster, Microshift or a Podman VM optimized for testing and development purposes
https://crc.dev
Apache License 2.0
1.26k stars 242 forks source link

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

Closed praveenkumar closed 4 months ago

praveenkumar commented 6 months ago

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 commented 6 months ago

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

Stop

https://github.com/crc-org/crc/blob/813c80a473046247eb232bb7e9e3da79a954118b/pkg/crc/machine/stop.go#L11

Delete

https://github.com/crc-org/crc/blob/813c80a473046247eb232bb7e9e3da79a954118b/pkg/crc/machine/delete.go#L25

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.

cfergeau commented 6 months ago

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 commented 6 months ago

I can do this /assign

anjannath commented 4 months ago

fixed in #4217