self linking of the component should not be there using odo link

[mohitsuman]

[kind/bug]

What versions of software are you using?

• Operating System: macOS
• Output of odo version: odo v0.0.16 (82968cb)

How did you run odo exactly?

Running odo from the binary.

Actual behavior

If I do odo link on the component and pass the same component name in the --component parameter, it works.

e.g. odo link nodejs --component nodejs

Expected behavior

We should handle this condition and make sure that self linking of the component is not allowed or a warning is shown.

[geoand]

Hi @mohitsuman

This indeed should not be possible, but I am curious to what led you to executing such a command?
Where you just trying to brake stuff or was something in the command names or help not clear?

Thanks

[mohitsuman]

Hi @geoand ,

We are working on OpenShift extension which uses odo under the hood. Now in the VSCode UI, when the user is given a list of components to link, it can be have the same component in the list and running the odo link succeeded into that.

We for now are handling this condition on UI and not showing the same component in the list to select, but it reminded us that odo link should also have a check for this.

[geoand]

@mohitsuman Thanks for the insight!

[jorgemoralespou]

I think this is something the CLI should probably not control. In this case, I think this is more a feature for the VSCode plugin and I think it solved the right way, by filtering the component there.

In any case, there's also the possibility to have the same component name in a different application, so if at any point, this issue is solved in odo, all different possibilities should be considered, which means that --app is not provided or if that it's provided it's not the same as current.

[kadel]

I think this is something the CLI should probably not control. In this case, I think this is more a feature for the VSCode plugin and I think it solved the right way, by filtering the component there.

In any case, there's also the possibility to have the same component name in a different application, so if at any point, this issue is solved in odo, all different possibilities should be considered, which means that --app is not provided or if that it's provided it's not the same as current.

Shouldn't odo check that user is not doing something stupid on invalid?
I think that self-linking should be something that odo should catch and error out.

Of course, it has to be smart enough to recognize that you are linking to a different component with the same name and allow that.

[geoand]

I think this is something the CLI should probably not control. In this case, I think this is more a feature for the VSCode plugin and I think it solved the right way, by filtering the component there.
In any case, there's also the possibility to have the same component name in a different application, so if at any point, this issue is solved in odo, all different possibilities should be considered, which means that --app is not provided or if that it's provided it's not the same as current.

Shouldn't odo check that user is not doing something stupid on invalid?
I think that self-linking should be something that odo should catch and error out.

Of course, it has to be smart enough to recognize that you are linking to a different component with the same name and allow that.

I agree that odo should try and prevent things that don't make sense

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[mohitsuman]

@dharmit any update for this ?

[dharmit]

@mohitsuman I'm adding this to our team discussion. Mainly because this is something we need to discuss for odo v2 as well even though this issue was opened for v1.

[mohitsuman]

@dharmit sure thing, let us know the discussion conclusion.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[dharmit]

@mohitsuman I'm closing this one since it's being tracked as an acceptance criterion on #3423.

/close

[openshift-ci-robot]

@dharmit: Closing this issue.

In response to this:

@mohitsuman I'm closing this one since it's being tracked as an acceptance criterion on #3423.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

@mohitsuman this has been fixed by #4777.