Odo: Move URLs from env to devfile

[mik-dass]

/kind feature

Which functionality do you think we should add?

• [ ] odo url create should create endpoint entries into the devfile instead of creating URLs in the env file.
• [ ] https://github.com/openshift/odo/pull/3665 will remove the secure flag temporarily. It should be restored and the attribute should be stored against the endpoint parameter secure
• [ ] should provide option to select the path of the url
• [ ] odo url list and odo url delete should list endpoints (with proper states) and delete from the devfile respectively.

Why is this needed?

This will help keep URLs in one place i.e the devfile and reduce confusion.

[kadel]

• [ ] odo url create should create endpoint entries into the devfile instead of creating URLs in the env file.
  *

Some information will still need to be stored in env.yaml. Not all information can be stored in devfile. host and kind will still need to be in env.yaml.
This means that URL information will be divided into two parts. Generic, and environment specific. Generic will be in devfile.yaml env specific in env.yaml.
Odo will need a reliable way to pair endpoints information from devfile.yaml to additional info that is stored in env.yaml.

[mik-dass]

Odo will need a reliable way to pair endpoints information from devfile.yaml to additional info that is stored in env.yaml.

I think we can use the URL name as the endpoint name. We can match the names and get rest of the info from the env yaml.

[yangcao77]

We cannot use the exact endpoint name as the URL name.

For example, I have two nodejs devfile components, and currently the endpoint is defined as

      endpoints:
        - name: http-3000
          targetPort: 3000

It won't allow me to push the second project, because route/ingress name 3000-tcp already exist in the current namespace

Suggest to use <endpoint name>-<component name> as the URL name.

OR we can use endpoint name as URL name, but append the component name at the end when creating route/ingress

[mik-dass]

Suggest to use - as the URL name.
OR we can use endpoint name as URL name, but append the component name at the end when creating route/ingress

OK :+1: We need to make sure that odo url list can retrieve and display the original name to the user.

The command odo url create should only create the endpoint in the first container to avoid confusion.

[kadel]

/priority high

[johnmcollier]

The command odo url create should only create the endpoint in the first container to avoid confusion.

@mik-dass What about adding a flag to allow users to specify the container when there's more than one container in a devfile?

I'm not sure how I feel about always creating the endpoint in the first container, because it limits the user's ability to add endpoints to multiple containers (without re-ordering their devfile manually).

E.g. in the springboot devfile:

schemaVersion: 2.0.0
metadata:
  name: java-springboot
  version: 1.0.0
projects:
  - name: springbootproject
    git:
      location: "https://github.com/odo-devfiles/springboot-ex.git"
components:
  - container:
      name: tools
      image: maysunfaisal/springbootbuild
      memoryLimit: 768Mi
      command: ['tail']
      args: [ '-f', '/dev/null']
      mountSources: true
      volumeMounts:
        - name: springbootpvc
          path: /data
  - container:
      name: runtime
      image: maysunfaisal/springbootruntime
      memoryLimit: 768Mi
      command: ['tail']
      args: [ '-f', '/dev/null']
      endpoints:
        - name: '8080/tcp'
          targetPort: 8080
      mountSources: false
      volumeMounts:
        - name: springbootpvc
          path: /data
  - volume:
      name: springbootpvc
      size: 4Gi
commands:
  - exec:
      id: devBuild
      component: tools
      commandLine: "/artifacts/bin/build-container-full.sh"
      workingDir: /projects
      group:
        kind: build
        isDefault: true
  - exec:
      id: devRun
      component: runtime
      commandLine: "/artifacts/bin/start-server.sh"
      workingDir: /
      group:
        kind: run
        isDefault: true

If we only added endpoints to the first container, odo url create --port 8443 would expose an endpoint in the build container, and not the runtime container like we want. This _may_ not be an issue now, since the containers are running on the same network in the pod, but it makes it harder to support the dedicatedPod field in the future for containers, where the containers in a devfile aren't guaranteed to run in the same pod.

[yangcao77]

This issue has dependency on
https://github.com/openshift/odo/pull/3702 - APIs to modify devfile entry
https://github.com/openshift/odo/pull/3665 - url creation using devfile endpoint entry

[yangcao77]

The command odo url create should only create the endpoint in the first container to avoid confusion.

devfile parsing generate an array to store endpoint entries, the order is not guaranteed. Propose to make --container a required flag if devfile contains more than one containers.

[kadel]

The command odo url create should only create the endpoint in the first container to avoid confusion.

devfile parsing generate an array to store endpoint entries, the order is not guaranteed. Propose to make --container a required flag if devfile contains more than one containers.

I'm not sure about that. The problem that I have with --container is that there is no way to list containers with odo from the command line. So we are forcing the user to read devfile.yaml.

I agree that there are legitime uses for --container but I don't want to complicated users' life if we don't have to. If there is no container with dedicatedPod it won't matter where the endpoint is defined, as all containers will end up in the same Pod with shared network namespace.

What if we do compromise.

• If there is a container that has dedicatedPod: true odo url create will error out with a message explaining that you need to use --container flag.
• If there is no container with dedicatedPod: true odo will create the endpoint on the first container. --container will be optional even if there multiple containers. If user really wants to create an endpoint for a specific container it will be possible.

[elsony]

Blocked by PR #3702

[kadel]

Blocked by PR #3702

this PR was merged

/remove-status blocked

[mik-dass]

@yangcao77 It might be a better idea to handle to handle list and describe in a different PR. I can see an existing issue https://github.com/openshift/odo/issues/3615 for them. Once the URLs are moved, somebody can pick up one of them and finish it in parallel. This will break our existing tests but we can comment them out for now.

[yangcao77]

I have this issue and #3615 implemented already, but I'm still working on unit tests and integration tests for it.
In case you want to review the code beforehand, I have created a draft PR:
https://github.com/openshift/odo/pull/3857
@mik-dass @girishramnani @kadel