serving DomainMapper complains path on Adressable Knative Broker

Following this guide: https://knative.dev/docs/serving/services/custom-domains/

I set these values in the "network" ConfigMap:

...
autocreateClusterDomainClaims: "true"
defaultExternalScheme: https
domainTemplate: '{{.Name}}-{{.Namespace}}.{{.Domain}}'
ingress.class: kourier.ingress.networking.knative.dev {code}
...

So I created a DomainMapping for a Knative Broker:

apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: default-borker.apps.my-server.somewhere.com
  namespace: default
spec:
  ref:
    name: default
    kind: Broker
    apiVersion: eventing.knative.dev/v1

But I am getting this:

...
Status:
  Address:
    URL:  default-borker.apps.my-server.somewhere.com
  Conditions:
    Last Transition Time:  2022-03-01T11:36:01Z
    Message:               autoTLS is not enabled
    Reason:                TLSNotEnabled
    Status:                True
    Type:                  CertificateProvisioned
    Last Transition Time:  2022-03-01T11:36:01Z
    Status:                True
    Type:                  DomainClaimed
    Last Transition Time:  2022-03-01T11:36:01Z
    Message:               Ingress has not yet been reconciled.
    Reason:                IngressNotConfigured
    Status:                Unknown
    Type:                  IngressReady
    Last Transition Time:  2022-03-01T11:36:01Z
    Message:               resolved URI "http://broker-ingress.knative-eventing.svc.cluster.local/default/default" contains a path
    Reason:                ResolveFailed
    Status:                False
    Type:                  Ready
    Last Transition Time:  2022-03-01T11:36:01Z
    Message:               resolved URI "http://broker-ingress.knative-eventing.svc.cluster.local/default/default" contains a path
    Reason:                ResolveFailed
    Status:                False
    Type:                  ReferenceResolved
  Observed Generation:     1
  URL:                     default-borker.apps.my-server.somewhere.com
Events:
  Type     Reason           Age                   From                      Message
  ----     ------           ----                  ----                      -------
  Normal   FinalizerUpdate  40m                   domainmapping-controller  Updated "default-borker.apps.my-server.somewhere.com" finalizers
  Warning  InternalError    2m14s (x20 over 40m)  domainmapping-controller  resolved URI "http://broker-ingress.knative-eventing.svc.cluster.local/default/default" contains a path

The guide does mention:

...as long as they conform to the Addressable contract...

IMO this error "contains a path" does break that

Mar 01 '22 12:03 matzew

What eventually made it work is to point to the Service of the Knative Broker Ingress, like:

apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: brokers.apps.ci-ln-ksz9nx2-72292.origin-ci-int-gce.dev.rhcloud.com
  namespace: knative-eventing
spec:
  ref:
    name: broker-ingress
    kind: Service
    apiVersion: v1

With this DomainMapping, I was able to curl the different brokers, based on their "path", like:

curl -v -X POST \
    -H "content-type: application/json"  \
    -H "ce-specversion: 1.0"  \
    -H "ce-source: curl-command"  \
    -H "ce-type: curl.demo"  \
    -H "ce-id: 123-abc"  \
    -d '{"message":"Hallo World"}' \
    https://brokers.apps.on.my.cloud.com/namespace/brokername

Mar 01 '22 12:03 matzew

When I do it with a KafkaChannel (using a host, instead of a path), like:

---
apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: kafka-channel-one.my-cloudy-server.com
  namespace: default
spec:
  ref:
    name: kafka-channel-one
    kind: KafkaChannel
    apiVersion: messaging.knative.dev/v1beta1

And it is ready, like:

k get kafkachannel
NAME                READY   REASON   URL                                                             AGE
kafka-channel-one   True             http://kafka-channel-one-kn-channel.default.svc.cluster.local   12m

I am getting this:

k get DomainMapping kafka-channel-one.my-cloudy-server.com -oyaml
apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"serving.knative.dev/v1alpha1","kind":"DomainMapping","metadata":{"annotations":{},"name":"kafka-channel-one.my-cloudy-server.com","namespace":"default"},"spec":{"ref":{"apiVersion":"messaging.knative.dev/v1beta1","kind":"KafkaChannel","name":"kafka-channel-one"}}}
    serving.knative.dev/creator: system:admin
    serving.knative.dev/lastModifier: system:admin
  creationTimestamp: "2022-03-01T14:00:06Z"
  finalizers:
  - domainmappings.serving.knative.dev
  generation: 1
  name: kafka-channel-one.my-cloudy-server.com
  namespace: default
  resourceVersion: "53229"
  uid: 64e966e6-0aa7-420f-8020-1874e0949380
spec:
  ref:
    apiVersion: messaging.knative.dev/v1beta1
    kind: KafkaChannel
    name: kafka-channel-one
    namespace: default
status:
  address:
    url: https://kafka-channel-one.my-cloudy-server.com
  conditions:
  - lastTransitionTime: "2022-03-01T14:00:07Z"
    message: autoTLS is not enabled
    reason: TLSNotEnabled
    status: "True"
    type: CertificateProvisioned
  - lastTransitionTime: "2022-03-01T14:00:07Z"
    status: "True"
    type: DomainClaimed
  - lastTransitionTime: "2022-03-01T14:00:07Z"
    message: Waiting for load balancer to be ready
    reason: Uninitialized
    status: Unknown
    type: IngressReady
  - lastTransitionTime: "2022-03-01T14:00:07Z"
    message: Waiting for load balancer to be ready
    reason: Uninitialized
    status: Unknown
    type: Ready
  - lastTransitionTime: "2022-03-01T14:00:07Z"
    status: "True"
    type: ReferenceResolved
  observedGeneration: 1
  url: https://kafka-channel-one.my-cloudy-server.com

Mar 01 '22 14:03 matzew

We use domain mapping in konk.dev and kn quickstart https://github.com/csantanapr/knative-kind/blob/master/05-eventing-samples.sh

Mar 02 '22 02:03 csantanapr

You're again referencing the Kubernetes Service.

KIngress doesn't currently support the ability to rewrite the request path (AFAIK), so the "supports Addressable" appears to be a bit broken. This should probably be fixed for GA one way or the other (either by removing the "general Addressable" support, or by supporting path mappings).

Mar 02 '22 04:03 evankanderson

We use domain mapping in konk.dev and kn quickstart https://github.com/csantanapr/knative-kind/blob/master/05-eventing-samples.sh

yes, and simple things like that do work - just not broker (for the error stated in the reason).

Mar 02 '22 07:03 matzew

You're again referencing the Kubernetes Service.

yes, as a reasonable work-around I use the actual k8s Service. and do the path fiddling for the different brokers on my end. At least something.

KIngress doesn't currently support the ability to rewrite the request path (AFAIK), so the "supports Addressable" appears to be a bit broken. This should probably be fixed for GA one way or the other (either by removing the "general Addressable" support, or by supporting path mappings).

yep, I agree - For the broker especially since they all (all implementations) do use the path strategy/approach, rather than behing an actual host (like with channels).

so the "supports Addressable" appears to be a bit broken.

yeah. I'd second that statement too :smile:

Mar 02 '22 07:03 matzew

This should probably be fixed for GA one way or the other (either by removing the "general Addressable" support, or by supporting path mappings).

I'd think that allowing path mappings is a huge benefit, so I'd def. like to see that happening

Mar 04 '22 06:03 matzew

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

Jun 03 '22 01:06 github-actions[bot]

/remove-lifecycle stale

Jun 14 '22 20:06 evankanderson

This is still blocking domain-mapping GA.

Jun 14 '22 20:06 evankanderson

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

Sep 13 '22 01:09 github-actions[bot]

This issue or pull request is stale because it has been open for 90 days with no activity.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle rotten
Close this issue or PR with /close

/lifecycle stale

Oct 13 '22 23:10 knative-prow-robot

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

Jan 15 '23 01:01 github-actions[bot]

/lifecycle frozen

Jan 17 '23 12:01 psschwei