Do not get project from env.yaml file

[feloy]

What type of PR is this:

/kind feature

What does this PR do / why we need it:

• set current namespace in env.yaml file when starting odo dev, remove it when cleanup
• do not read project from env.yaml file when running odo dev (or any other command)
• env.yaml file is not created when running odo deploy
• the existence of env.yaml file is not checked when running odo delete component, odo build-images (or any other command)

Which issue(s) this PR fixes:

Fixes #6018

PR acceptance criteria:

• [x] Unit test

• [x] Integration test

• [ ] Documentation

How to test changes / Special notes to the reviewer:

[netlify[bot]]

✅ Deploy Preview for odo-docusaurus-preview ready!

Name	Link
🔨 Latest commit	fa6ae2ef3fa9b5c106946427ee131a3487fd98cd
🔍 Latest deploy log	https://app.netlify.com/sites/odo-docusaurus-preview/deploys/62ff69e62eaaaa0008e25e17
😎 Deploy Preview	https://deploy-preview-6025--odo-docusaurus-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[odo-robot[bot]]

Unit Tests on commit aca2a6c81144abb79d03e5f8b95f6a9145d90d83 finished successfully. View logs: TXT HTML

[odo-robot[bot]]

Windows Tests (OCP) on commit aca2a6c81144abb79d03e5f8b95f6a9145d90d83 finished successfully. View logs: TXT HTML

[odo-robot[bot]]

Validate Tests on commit aca2a6c81144abb79d03e5f8b95f6a9145d90d83 finished successfully. View logs: TXT HTML

[odo-robot[bot]]

Kubernetes Tests on commit aca2a6c81144abb79d03e5f8b95f6a9145d90d83 finished successfully. View logs: TXT HTML

[odo-robot[bot]]

OpenShift Tests on commit aca2a6c81144abb79d03e5f8b95f6a9145d90d83 finished successfully. View logs: TXT HTML

[dharmit]

@feloy running odo dev from this PR doesn't store the port information in the state file. I think that's a regression, right?

[dharmit]

We also need to update the env file section of the docs to reflect the changes made here, no?

[dharmit]

@feloy I think this warning message shouldn't be printed anymore. If I wanted to deploy my component in a particular namespace, this is the way to do it, since the namespace won't be stored in env.yaml after this PR is merged. WDYT?

$ odo set namespace default  
 ⚠  This is being executed inside a component directory. This will not update the namespace of the existing component

[dharmit]

What I am describing below was purposefully done to break stuff.

I first created an Operator backed service in the namespace myproject.

1. odo dev in dir1. Component gets pushed to the namespace myproject. Keep this running.
2. cd to dir2 and set the namespace using odo set namespace default. odo dev pushes to the namespace default. Keep it running or stop it, doesn't matter.
3. cd to dir1 and do odo add binding (interactive mode) and choose the option "current namespace".

At step 3, odo says it can't find any bindable services in the current namespace. I am not suggesting that this is incorrect/invalid behaviour. I'm simply wondering what should the behaviour be:

1. Should it, as is currently the case, fail to list bindable services since step 2 above changed the kubeconfig to use default namespace?
2. Or, should odo smartly figure that since the env.yaml file does have a namespace set, it shouldn't use the namespace pointed to by kubeconfig but use the one in env.yaml instead?

[feloy]

@feloy running odo dev from this PR doesn't store the port information in the state file. I think that's a regression, right?

I tested it but cannot reproduce. Can you share the steps to reproduce?

[dharmit]

I tested it but cannot reproduce. Can you share the steps to reproduce?

@feloy my bad. I was looking into env.yaml instead of devstate.json. me--. 😞

[feloy]

What I am describing below was purposefully done to break stuff.

I first created an Operator backed service in the namespace myproject.

1. odo dev in dir1. Component gets pushed to the namespace myproject. Keep this running.
2. cd to dir2 and set the namespace using odo set namespace default. odo dev pushes to the namespace default. Keep it running or stop it, doesn't matter.
3. cd to dir1 and do odo add binding (interactive mode) and choose the option "current namespace".

At step 3, odo says it can't find any bindable services in the current namespace. I am not suggesting that this is incorrect/invalid behaviour. I'm simply wondering what should the behaviour be:

1. Should it, as is currently the case, fail to list bindable services since step 2 above changed the kubeconfig to use default namespace?
2. Or, should odo smartly figure that since the env.yaml file does have a namespace set, it shouldn't use the namespace pointed to by kubeconfig but use the one in env.yaml instead?

I'm pretty sure we don't want anymore odo to be smart to detect the right namespace for the user, as we have seen that it is counter-productive: users generally knows very well on which namespace they are operating (lots of people are setting the current Kubernetes namespace in the PS1 of their shell!), and making odo operate in another namespace is disturbing for the user.

[kadel]

What I am describing below was purposefully done to break stuff. I first created an Operator backed service in the namespace myproject.

1. odo dev in dir1. Component gets pushed to the namespace myproject. Keep this running.
2. cd to dir2 and set the namespace using odo set namespace default. odo dev pushes to the namespace default. Keep it running or stop it, doesn't matter.
3. cd to dir1 and do odo add binding (interactive mode) and choose the option "current namespace".

At step 3, odo says it can't find any bindable services in the current namespace. I am not suggesting that this is incorrect/invalid behaviour. I'm simply wondering what should the behaviour be:

1. Should it, as is currently the case, fail to list bindable services since step 2 above changed the kubeconfig to use default namespace?
2. Or, should odo smartly figure that since the env.yaml file does have a namespace set, it shouldn't use the namespace pointed to by kubeconfig but use the one in env.yaml instead?

I'm pretty sure we don't want anymore odo to be smart to detect the right namespace for the user, as we have seen that it is counter-productive: users generally knows very well on which namespace they are operating (lots of people are setting the current Kubernetes namespace in the PS1 of their shell!), and making odo operate in another namespace is disturbing for the user.

Originally I was thinking about the scenario that @dharmit mentioned as well so I thought that we would still have namespace in env.yaml for the duration of the odo dev run.

@feloy has a point, this could still be misleading for some users. Let's keep it simple and just use the current namespace.

/approve

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kadel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [kadel]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
1.2% Duplication

[dharmit]

Originally I was thinking about the scenario that @dharmit mentioned as well so I thought that we would still have namespace in env.yaml for the duration of the odo dev run.

@feloy has a point, this could still be misleading for some users. Let's keep it simple and just use the current namespace.

Yep. In fact, when I was breaking odo for specifically that scenario, it felt like going a bit over the board to just break odo. We can wait till some users share feedback around it.

[feloy]

/override ci/prow/v4.10-integration-e2e Tests pass on IBM Cloud

[openshift-ci[bot]]

@feloy: Overrode contexts on behalf of feloy: ci/prow/v4.10-integration-e2e

In response to this:

/override ci/prow/v4.10-integration-e2e Tests pass on IBM Cloud

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.