Provide way to name port when using 'oc expose' so get service/protocol DNS SRV entries.

[GrahamDumpleton]

It is not possible using oc expose dc to create a headless service definition which correctly sets up DNS SRV entries of the form:

_service._proto.name

This is because you can't name the port definition created from the command line and a sensible default is not added when creating a headless service.

Version

$ oc version
oc v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth

Server https://api.pro-ap-southeast-2.openshift.com:443
openshift v3.7.9
kubernetes v1.7.6+a08f5eeb62

Steps To Reproduce

Run:

$ oc expose dc/blog-django-py --name blog-django-py-metrics --cluster-ip=None --port 8081 --dry-run -o json
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "blog-django-py-metrics",
        "creationTimestamp": null,
        "labels": {
            "app": "blog-django-py"
        }
    },
    "spec": {
        "ports": [
            {
                "protocol": "TCP",
                "port": 8081,
                "targetPort": 8081
            }
        ],
        "selector": {
            "app": "blog-django-py",
            "deploymentconfig": "blog-django-py"
        },
        "clusterIP": "None"
    },
    "status": {
        "loadBalancer": {}
    }
}

There is no spec.ports.name field and so the required DNS SRV entries are not created. If you add a name field with value myservice, then you can lookup:

_myservice._tcp.blog-django-py-metrics

It is important that the full version is added because some services rely on being able to extract the port number from the SRV entry. Without the name for the port, the SRV entry created and which can be queried using blog-django-py-metrics has port set to 0. There is no protocol specific entry.

There are probably two alternatives to having an option to provide a name.

The first is do like oc expose when not setting --cluster-ip to None.

In that case it generates:

  ports:
  - name: 8080-tcp
    port: 8080
    protocol: TCP
    targetPort: 8080

So gives it a generated name.

This would result in DNS SRV entries, but the name you need to use is clumsy. That is, have to use:

_8081-tcp._tcp.blog-django-py-metrics

Works but duplicates protocol name.

>>> for item in dns.resolver.query('_8081-tcp._tcp.blog-django-py-metrics.metrics.svc.cluster.local', 'SRV'): item
...
<DNS IN SRV rdata: 10 25 8081 2555bb89.blog-django-py-metrics.metrics.svc.cluster.local.>
<DNS IN SRV rdata: 10 25 8081 830bdb18.blog-django-py-metrics.metrics.svc.cluster.local.>
<DNS IN SRV rdata: 10 25 8081 aeb532de.blog-django-py-metrics.metrics.svc.cluster.local.>
<DNS IN SRV rdata: 10 25 8081 a432c21f.blog-django-py-metrics.metrics.svc.cluster.local.>

The -tcp suffix was probably added to avoid error:

error: services "blog-django-py-metrics" could not be patched: cannot convert int64 to string

when try to set it to just 8081 for name. IOW, will not accept just an integer.

The second alternative is that even if the port isn't named, create a DNS SRV entry anyway, where the service name is set to the port number. This means you could query on:

_8081._tcp.blog-django-py-metrics

BTW, you can't even create a definition using oc create service clusterip, as it will fail when you supply --port option at same time as --clusterip=None.

$ oc create service clusterip xxx --clusterip=None --tcp=8081 --dry-run -o json
error: can not map ports with clusterip=None

All up, support in this area for setting up headless service entries where want DNS SRV entries of form _service._proto.name from the command line could be better. Have no choice but to resort to using raw resource definitions and oc create -f.

[GrahamDumpleton]

Hmmm, just to be inconsistent, if you don't specify --port to oc expose, you do get names.

$ oc expose dc/blog-django-py --name blog-django-py-headless --cluster-ip=None -o json --dry-run
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "blog-django-py-headless",
        "creationTimestamp": null,
        "labels": {
            "app": "blog-django-py"
        }
    },
    "spec": {
        "ports": [
            {
                "name": "port-1",
                "protocol": "TCP",
                "port": 8080,
                "targetPort": 8080
            },
            {
                "name": "port-2",
                "protocol": "TCP",
                "port": 8081,
                "targetPort": 8081
            }
        ],
        "selector": {
            "app": "blog-django-py",
            "deploymentconfig": "blog-django-py"
        },
        "clusterIP": "None"
    },
    "status": {
        "loadBalancer": {}
    }
}

But obviously you cannot be certain which name is used for which port if there is more than one port.

If when using --port, if at least created a name of port-1, that would be a start. So maybe that is the change required. Still give a default name when --port used. Still would be nicer if could supply the name.

[jwforres]

@openshift/sig-networking

[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

[GrahamDumpleton]

/lifecycle frozen