Url create support for devfile ingress

[elsony]

Related to #2470

User Story

As a user, I want to expose my service over ingress using either secure or non-secure connection.

Acceptance Criteria

• Example:$ odo url create --port 8081 --ingressDomain xx
• Secure example:$ odo url create --port 8081 --secure --ingressDomain xx
• It should enable HTTPS when the secure parameter has been specified
• create .odo/env folder to store environment specific information, e.g. ingressDomain

/kind user-story
/area devfile

[yangcao77]

/assign

[girishramnani]

There is a correlated issue of occlient here #2561
cc @mik-dass

[yangcao77]

When Experimental=true, the devfile path has been chosen. udo url would create an ingress instead of Openshift route.

odo url create <clusterHost> --secure true
The optional flags port and secure work the same as current existing odo url.
<clusterHost> is required to be provided.

The ingressDomain will be generated with the format <componentName>-<port>.<clusterHost>

If secure=true, a self-signed certificate will be created and a tls secret & ingress will be created using the certificate.

[yangcao77]

Here are the detailed information on the https support:

• The certificate will use x509 with rsa key.
• SerialNumber will use time.Now() and encoded to make sure of the uniqueness.
• All ingresses of a single component will share the same ssl certificate & tls secret. If secure=true will check if there is a valid tls secret existing for the component, if exists, use the existing one; if not, create a new one.
• The tls secret will not be deleted by odo url delete. It will only be deleted when the component is deleted.

[yangcao77]

stephaniesmbp2:springtest1 stephanie$ kubectl get ingress
NAME                          HOSTS                               ADDRESS   PORTS     AGE
spring-springtest1-gldv-8080-app    spring-springtest1-gldv-8080.9.42.26.107.nip.io              80, 443   9d
stephaniesmbp2:springtest1 stephanie$ kubectl get ingress spring-springtest1-gldv-app -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  creationTimestamp: "2020-02-04T20:22:56Z"
  generation: 1
  labels:
    app.kubernetes.io/component-name: spring-springtest1-gldv
    app.kubernetes.io/name: app
    app.kubernetes.io/url-name: spring-springtest1-gldv
  name: spring-springtest1-gldv-8080-app
  namespace: che
  resourceVersion: "30805111"
  selfLink: /apis/extensions/v1beta1/namespaces/che/ingresses/spring-springtest1-gldv-app
  uid: 214270b5-478c-11ea-9ee2-005056a01f13
spec:
  rules:
  - host: spring-springtest1-gldv-8080.9.42.26.107.nip.io
    http:
      paths:
      - backend:
          serviceName: spring-springtest1-gldv-app
          servicePort: 8080
        path: /
  tls:
  - hosts:
    - spring-springtest1-gldv-8080.9.42.26.107.nip.io
    secretName: spring-springtest1-gldv-tlssecret
status:
  loadBalancer: {}

[girishramnani]

we need to consider differentiating environment specific information from non-specific stuff.

[kadel]

• Example:$ odo url create --port 8081 --ingressDomain xx

What is this command going to do exactly?
Currently, the odo url create command just records the information about the url into local config, and then later when odo push is called it creates the resources on the cluster.

In this scenario where devfile is used, where would odo url create store the information and configuration?

One potential issue that I can see here is where we should store information about the URL.
The information about for what port URL should be created is something that should be devfile itself, as this is tight to the project/application definition.
But ingressDomain is something that is environment-specific (it will be different depending on which cluster you are deploying your application to).

[elsony]

The current proposal is to store any environment specific info under a new folder called .odo/env. This folder will be the home for storing anything that is environment specific information on the project. The ingressDomain will be stored in a file under that folder. Given that this item is the first consumer of storing environment specific info, the implementation of adding .odo/env will be part of this issue.

[yangcao77]

odo url create <clusterHost> --secure true
Upon creation, user only needs to provide the clusterHost. The clusterHost will be stored under env file under ./odo/env.

The port number is assumed to be stored as entryPointin the devfile, and will be read directly from devfile, during odo push
The prefix of the ingress domain will be <odoComponentName>-<port number>

During odo push, we will check if there is a ingress domain stored under the env file, if there is, we will create a ingress. If there is no entry point in the devfile, an error will be shown since no ingress can be created.

[kadel]

odo url create <clusterHost> --secure true
Upon creation, user only needs to provide the clusterHost. The clusterHost will be stored under env file under ./odo/env.

+1 for stroring clusterHost in .odo/env

In the current odo version, the positional argument in odo url create <url name> command is the url name, that needs to be unique. The reason is that the user should also be able to remove the url using odo url delete <url name>.

If we use the cluster host, then how would the user create multiple URLs with the same cluster host?

The port number is assumed to be stored as entryPointin the devfile, and will be read directly from devfile, during odo push

What happens if there is an entryPoint in devfile but no record on .odo/env for it?

[yangcao77]

As long as the & is unique. Users can create multiple URLs with the same cluster.

If there is an entryPoint but no clusterHost is provided. An error/warning will be shown during odo push, since we parse& check the devfile content during push.

[kadel]

I was actually expecting that it would work slightly differently.
The URL should be represented with previewUrl in devfile. (https://github.com/redhat-developer/devfile/blob/master/docs/devfile.md#
^ wrong assumption, previewUrl in devfile is for some reason tied to command

Let's assume that devfile has only one endpoint and one container (like this one https://github.com/eclipse/che-devfile-registry/blob/master/devfiles/java-web-spring/devfile.yaml).

Running odo url create myurl --domain my.example.com will add information to .odo/env that the domain my.example.com should be paired with port 8080.
Devfile has only one endpoint (8080) so we can assume that the user wants to use that.
If there would be more, the command should complain.

Running odo url create myurl --port 8081 --domain my.example.com will add previewUrl endpoint record to the devfile.yaml , and pairing with my.example.com will be recorded in .odo/env

There should be also --path flag in the future to allow map different path on the same domain.

odo url create users --port 8080 --domain my.example.com --path /users
odo url create admin --port 8081 --domain my.example.com --path /admin

But devfile format needs to support this first.

Running odo push will read the devfile.yaml and .odo/env and create the Kubernetes resources including Ingress based on information in devfile and .odo/env

[kadel]

As long as the & is unique. Users can create multiple URLs with the same cluster.

how it will be shown in odo url list? and how will user specify what url to delete in odo url delete command? The Ingress name?
I would find that pretty confusing as a user if I create something calling odo url create example.com but I delete it running odo url delete mycomponent-8080 especially if I need to script this.

[kadel]

If there is an entryPoint but no clusterHost is provided. An error/warning will be shown during odo push, since we parse& check the devfile content during push.

I think entrypoint should be mapped to Service (#2622) and previewUrl to Ingress

^ wrong assumption, previewUrl in devfile is for some reason tied to command

[yangcao77]

The pr has been merged. Can we close this issue?

[kadel]

/close

[openshift-ci-robot]

@kadel: Closing this issue.

In response to this:

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