name service ports to make it work with openshift routes

[surajssd]

Issue desc:

So if you have a kubernetes service with unnamed port and when you create a route for this service on openshift, openshift gives you a warning in the web console saying

Service web has a single, unnamed port. A route cannot specifically target an unnamed service port. If more service ports are added later, the route will also direct traffic to them.

So what this means is that if you update the service later to have multiple ports and if they are unnamed, then route traffic will be sent to all of them.

Steps to reproduce:

$ kedge version
0.2.0 (0a0b9a9)

$ oc new-project foo
Now using project "foo" on server "https://192.168.42.2:8443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git

to build a new example application in Ruby.

$ kedge init --image centos/httpd --name web -p 80
file kedge.yml created

$ cat kedge.yml 
name: web
containers:
- image: centos/httpd
services:
- ports:
  - port: 80

$ kedge create -f kedge.yml 
service "web" created
deployment "web" created

$ minishift console
Opening the OpenShift Web console in the default browser...

Now goto the service web and click create route button. There in the form you will see this particular warning shown:

Service web has a single, unnamed port. A route cannot specifically target an unnamed service port. If more service ports are added later, the route will also direct traffic to them.

What is expected to happen

Name the service ports, just for being on the safe side.

[kadel]

This will become relevant when we add support for Routes.

related to #238

[concaf]

So, first I created a Service with the file -

name: web
containers:
- image: centos/httpd
services:
- ports:
  - port: 80

I exposed this service like -

$ oc expose service web --name=first
route "first" exposed
$ oc describe route first
Name:                   first
Namespace:              myproject
Created:                11 seconds ago
Labels:                 app=web
Annotations:            openshift.io/host.generated=true
Requested Host:         first-myproject.192.168.42.69.nip.io
                          exposed on router router 11 seconds ago
Path:                   <none>
TLS Termination:        <none>
Insecure Policy:        <none>
Endpoint Port:          80

Service:        web
Weight:         100 (100%)
Endpoints:      172.17.0.3:80

The endpoint port is 80.

I then add a service port like -

name: web
containers:
- image: centos/httpd
services:
- ports:
  - port: 80
  - port: 81

Then -

$ kedge apply -f test.yml 
service "web" configured
deployment "web" configured

The route I created earlier continues to work since it's not bound to a Service Port name, but to the port number itself, 80 in this case.

I create a new route -

$ oc expose service web --name=second
route "second" exposed
$ oc describe route second
Name:                   second
Namespace:              myproject
Created:                6 seconds ago
Labels:                 app=web
Annotations:            openshift.io/host.generated=true
Requested Host:         second-myproject.192.168.42.69.nip.io
                          exposed on router router 6 seconds ago
Path:                   <none>
TLS Termination:        <none>
Insecure Policy:        <none>
Endpoint Port:          web-80

Service:        web
Weight:         100 (100%)
Endpoints:      172.17.0.3:80, 172.17.0.3:81

This route also works fine, and the endpoint is the Service Port name this time (web-80)

The earlier route also continues to work fine and route traffic to endpoint port i.e. 80.
Maybe this is a quirk with the web console, but works as expected for me.

I don't see why should we be naming all the ports?

[surajssd]

Endpoints: 172.17.0.3:80, 172.17.0.3:81

@containscafeine ^^

The warning does not say it won't work!

[concaf]

Hmm, so why should we be populating all names?

[surajssd]

Right now we are auto-generating name for ports when more than one port is given, if we are doing it for more than one port why should we even wait for that why not do it anyway be it one port or multiple port. What I am trying to imply here is that if one port is given is not a special case here that we should be checking.

In other places like this where we are doing similar checks is in case of container names, where we check if container is one then not giving name is ok but if more than one containers are provided and names are not given it is not ok and since there we do not generate names automatically so we fail there. In that case whether single item is given in list without name makes a speacial case that we need to test.

But here since we are not failing but auto-populating names I think checking for single port not having name does not make any sense at all, since it is not a special case anymore.

@containscafeine

Hmm, so why should we be populating all names?

A route cannot specifically target an unnamed service port. If more service ports are added later, the route will also direct traffic to them.

[concaf]

I think our behavior should be consistent with the way OpenShift deals with this.
If we add more service ports to OpenShift later on, then it routes traffic to all of them, so should we.
We should not be auto naming the first port and bind the route to that port, when OpenShift does not do that.

[kadel]

I don't understand where is the problem if we start naming ports from the beginning if name is not set.

[concaf]

@kadel @surajssd -

• User specifies one unnamed service port:

In Kedge - The generated route will be bound with that service port name. On addition of subsequent service ports, the route will not direct traffic to the newer ports.

In OpenShift - The generated route will not be bound with that particular service port. On addition of subsequent ports, the route will direct traffic to newer ports.

IMO, Kedge is behaving differently than OpenShift for the same input, which is inconsistent :(

[kadel]

In Kedge - The generated route will be bound with that service port name. On addition of subsequent service ports, the route will not direct traffic to the newer ports.

In OpenShift - The generated route will not be bound with that particular service port. On addition of subsequent ports, the route will direct traffic to newer ports.

It depends on how you define Route/Ingress. Nothing to do if port is named or not.
Both cases can be set to behave either way.

[kadel]

@containscafeine I don't really see the problem in naming ports if the name is provided.

[concaf]

Okay, we can move ahead with one.
I don't agree completely, but I understand your point.
Yay 🎉