Closed
Description
Describe the bug
The default Route
resource created has no programmatic means to apply TLS config.
Upon reading https://quarkus.io/guides/deploying-to-kubernetes#using-existing-resources I assumed I could create an src/main/kubernetes/openshift.yml
file like this:
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: example-api
spec:
tls:
termination: edge
insecureEdgeTerminationPolicy: Redirect
and it could generated something like this:
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
app.openshift.io/vcs-url: <<unknown>>
app.quarkus.io/commit-id: <<example>>
app.quarkus.io/build-timestamp: <<example>>
labels:
app.openshift.io/runtime: quarkus
app.kubernetes.io/version: 1.0.0
app.kubernetes.io/name: example-api
app.kubernetes.io/part-of: core
name: example-api
spec:
host: example-api.hostname.com
port:
targetPort: http
tls:
insecureEdgeTerminationPolicy: Redirect
termination: edge
to:
kind: Service
name: colony-legacy-api
But instead it omits everything it would normally generate except annotations and labels:
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
app.openshift.io/vcs-url: <<unknown>>
app.quarkus.io/commit-id: <<example>>
app.quarkus.io/build-timestamp: <<example>>
labels:
app.openshift.io/runtime: quarkus
app.kubernetes.io/version: 1.0.0
app.kubernetes.io/name: example-api
app.kubernetes.io/part-of: core
name: example-api
spec:
tls:
insecureEdgeTerminationPolicy: Redirect
termination: edge
Quarkus version or git rev
2.15.0
Activity
quarkus-bot commentedon Dec 15, 2022
/cc @Sgitario(kubernetes), @geoand(kubernetes,openshift), @iocanel(kubernetes,openshift)
Split the route decorator to allow custom resources
Sgitario commentedon Dec 16, 2022
This needs to be fixed first in Dekorate: dekorateio/dekorate#1112
Split the route decorator to allow custom resources
Split the route decorator to allow custom resources
Bump Dekorate to version 3.1.3
Bump Dekorate to version 3.1.3
Bump Dekorate to version 3.1.3
3 remaining items