DomainMapper complains path on Adressable Knative Broker

[matzew]

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

[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

[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

[csantanapr]

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

[evankanderson]

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

[matzew]

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

[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 😄

[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

[github-actions]

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.

[evankanderson]

/remove-lifecycle stale

[evankanderson]

This is still blocking domain-mapping GA.

[github-actions]

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.

[knative-prow-robot]

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

[github-actions]

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.

[psschwei]

/lifecycle frozen