Feature: Possibility to control config-domain CM's data part and Gateway CR's servers part from KnativeServing CR
Describe the feature
It would be a nice feature to integrate the config-domain configMap data part to the following resource when knative operator is used for example:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
name: knative-serving
namespace: knative-serving
spec:
config-domain:
data:
knative.my.domain.net: ""
Instead of this cm:
apiVersion: v1
data:
knative.my-domain.net: ""
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/name: knative-serving
app.kubernetes.io/version: 1.12.0
name: config-domain
namespace: knative-serving
So I wouldn't have to update the cm. Why it is needed? When I apply the knative serving CR with Terraform with a little change, the config-domain cm is overwritten with the default cm again, and all of my services will be unreachable until I adjust my custom hostname.
It would be also good to have a possibility to set the Gateway:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
name: knative-serving
namespace: knative-serving
spec:
istio:
ingressGateway:
servers:
- hosts:
- '*'
port:
name: http
number: 80
protocol: HTTP
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
credentialName: tls-cert
mode: SIMPLE
Instead of this
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: knative-ingress-gateway
namespace: knative-serving
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- '*'
port:
name: http
number: 80
protocol: HTTP
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
credentialName: tls-cert
mode: SIMPLE
The resason is the same, I have Terraform and I apply the knative-serving CR as kubectl manifest, but when I change anything in the knativeserving CR the Gateway config will be the default one and I will get connection refused for my HTTPS requests until I adjust my changes again. Thank you very much for your help inadvance!
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.