Allow multiple odo users share one namespace

[kadel]

/kind user-story

User Story

As a development team leader (team uses odo) I want my team to be able to use one shared namespace So developers can easily share resources

Acceptance Criteria

• It should be possible to execute odo dev multiple times with the same devfile against the same namespace

Notes

• Use a consistent naming scheme for all resources handled by odo

/kind user-story

[valaparthvi]

If everyone is working on the same resource at the same time, wouldn't it cause conflicts?

[feloy]

It should be possible to execute odo dev multiple times with the same devfile against the same namespace

The use case would be for devs of the same team, working on the same component into the same cluster/namespace

[valaparthvi]

If everyone is working on the same resource at the same time, wouldn't it cause conflicts?

New resources will be created for every user.

[dharmit]

@kadel we had a bunch of conversation around this in the last backlog grooming call. One of the things you mentioned was to let multiple users be able to do odo dev for the same component at the same time. And the way this could be done is to store component name in env.yaml.

But then #5780 is about doing the opposite. I'm only concerned that work done to accomplish #5780 might get invalidated if we go ahead with this issue.

[kadel]

But then #5780 is about doing the opposite. I'm only concerned that work done to accomplish #5780 might get invalidated if we go ahead with this issue.

I think that #5780 is still valid. What we are currently doing (saving name in env.yaml) is not good, and it creates a lot of o problems. It still make sense to not save name and just use name from devfile.

Regarding sharing the namespace between multiple developers, this will require a lot more change and probably even some design changes (I still don't know what we will do with kubernetes component names).

You are right that both #5780 and this issues are both about names. But as I see it #5780 is about "undoing" what we are currently doing, and then this issue is about implementing a new strategy. I don't think that one invalidates the other, but rather #5780 is the first step (cleanup) before doing bigger changes.

[cdrage]

Current status: Waiting for more feedback before continuing with implementation

[kadel]

lowering priority as we haven't heard anything about this in a while, so I assume that it is not an adoption blocker for anyone

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

[rm3l]

Still relevant.

/remove-lifecycle stale
/lifecycle frozen