Allow running multiple parallel Dev sessions on the same platform type

[valaparthvi]

/kind user-story

User Story

As an odo user, I want to be able to run 2 parallel Dev session on different clusters (or on podman and docker for e.g.), So that I can simultaneously check my application/cluster's behavior instead of having to restart the Dev sessions and moving back and forth between the clusters/Container runtimes.

Acceptance Criteria

• It should allow to run multiple dev sessions on different clusters.
• It should allow to run multiple dev sessions on podman and docker or 2 different versions of container runtimes.

Current Behavior:

$ KUBECONFIG=some_config odo dev
  __
 /  \__     Developing using the "springboot" Devfile
 \__/  \    Platform: cluster
 /  \__/    odo version: v3.10.0
 \__/

↪ Running on podman in Dev mode
 ✗  unable to save state file: a session with PID 21535 is already running on platform "cluster"

$ PODMAN_CMD=docker odo dev
  __
 /  \__     Developing using the "springboot" Devfile
 \__/  \    Platform: podman
 /  \__/    odo version: v3.10.0
 \__/

↪ Running on podman in Dev mode
 ✗  unable to save state file: a session with PID 22552 is already running on platform "podman"

Links

• Related Epic (mandatory):

/kind user-story

Notes

Currently the validation relies on checking for platform in the .odo/devstate.*.json path. This could be fixed by also storing the KUBECONFIG and PODMAN_CMD in the file and additionally relying on their values to determine if the user is trying to run a duplicate session.

[feloy]

Grooming (2023-05-11)

We could consider adding a DOT_ODO_DIRECTORY environment variable to change the directory on which devstate files are stored.

[github-actions]

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.

[valaparthvi]

@rm3l is this still relevant? I see it's pointed, so it was relevant at some point.

[rm3l]

is this still relevant? I see it's pointed, so it was relevant at some point.

Makes sense to keep it open, indeed, as it had been pointed and prioritized.
Thanks for commenting out.

/remove-lifecycle stale
/lifecycle frozen