feat(snc): add serverless profiles for Knative Serving and Eventing

[jangel97]

Add three serverless profiles:

• serverless-serving: installs OpenShift Serverless operator and KnativeServing
• serverless-eventing: installs OpenShift Serverless operator and KnativeEventing
• serverless: installs OpenShift Serverless operator with both KnativeServing and KnativeEventing

[jangel97]

Testing

All three profiles were tested on a fresh SNC cluster (OCP 4.21.0, spot instance).

--profile serverless-serving

./out/mapt aws openshift-snc create \
    --project-name jmorenas-snc-test \
    --backed-url file:///tmp/mapt-workspace \
    --version 4.21.0 \
    --pull-secret-file <pull-secret> \
    --conn-details-output /tmp/snc \
    --spot --tags owner=jmorenas \
    --profile serverless-serving

export KUBECONFIG=/tmp/snc/kubeconfig

Operator installed successfully:

$ oc get csv -n openshift-serverless
NAME                          DISPLAY                        VERSION   REPLACES                      PHASE
serverless-operator.v1.37.1   Red Hat OpenShift Serverless   1.37.1    serverless-operator.v1.37.0   Succeeded

KnativeServing Ready with all conditions True:

$ oc get knativeserving knative-serving -n knative-serving -o jsonpath='{.status.conditions}' | jq .
[
  { "status": "True", "type": "DependenciesInstalled" },
  { "status": "True", "type": "DeploymentsAvailable" },
  { "status": "True", "type": "InstallSucceeded" },
  { "status": "True", "type": "Ready" },
  { "status": "True", "type": "VersionMigrationEligible" }
]

All serving pods running:

$ oc get pods -n knative-serving
NAME                                                            READY   STATUS      RESTARTS   AGE
activator-649db9897b-8pvqk                                      2/2     Running     0          3m53s
activator-649db9897b-cn5l4                                      2/2     Running     0          4m8s
autoscaler-9f9b55c86-6l94h                                      2/2     Running     0          4m8s
autoscaler-9f9b55c86-kvkxv                                      2/2     Running     0          4m8s
controller-6f9bc6799-tjt75                                      2/2     Running     0          3m43s
controller-6f9bc6799-zjxtr                                      2/2     Running     0          4m3s
webhook-b866f549b-l8qmb                                         2/2     Running     0          3m52s
webhook-b866f549b-x7fbk                                         2/2     Running     0          4m7s

Deployed a Knative Service and verified it serves traffic:

$ oc apply -f - <<EOF
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "World"
EOF

$ oc get ksvc
NAME    URL                                      LATESTCREATED   LATESTREADY   READY   REASON
hello   https://hello-default.apps-crc.testing   hello-00001     hello-00001   True

$ oc run curl-test --restart=Never --image=quay.io/curl/curl \
    -- curl --silent -k https://hello-default.apps-crc.testing
$ oc wait --for=jsonpath='{.status.phase}'=Succeeded pod/curl-test --timeout=60s
pod/curl-test condition met

$ oc logs curl-test
Hello World!

--profile serverless-eventing

./out/mapt aws openshift-snc create \
    --project-name jmorenas-snc-test \
    --backed-url file:///tmp/mapt-workspace \
    --version 4.21.0 \
    --pull-secret-file <pull-secret> \
    --conn-details-output /tmp/snc \
    --spot --tags owner=jmorenas \
    --profile serverless-eventing

export KUBECONFIG=/tmp/snc/kubeconfig

KnativeEventing Ready:

$ oc get knativeeventing -n knative-eventing
NAME               VERSION   READY   REASON
knative-eventing   1.37.1    True

Deployed a PingSource and verified events are delivered:

$ oc new-project test-eventing

$ oc apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: event-display
  namespace: test-eventing
spec:
  replicas: 1
  selector:
    matchLabels:
      app: event-display
  template:
    metadata:
      labels:
        app: event-display
    spec:
      containers:
      - name: event-display
        image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
---
apiVersion: v1
kind: Service
metadata:
  name: event-display
  namespace: test-eventing
spec:
  selector:
    app: event-display
  ports:
  - port: 80
    targetPort: 8080
EOF

$ oc wait --for=condition=Available deployment/event-display -n test-eventing --timeout=120s

$ oc apply -f - <<'EOF'
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: test-ping
  namespace: test-eventing
spec:
  schedule: "*/1 * * * *"
  data: '{"message": "Hello from Knative Eventing!"}'
  sink:
    ref:
      apiVersion: v1
      kind: Service
      name: event-display
EOF

$ oc wait pingsource/test-ping -n test-eventing --for=condition=Ready --timeout=60s

$ oc logs $(oc get po -o name -l app=event-display)
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/test-eventing/pingsources/test-ping
  id: 31211f2a-7313-4207-85c5-ee79c4972465
  time: 2026-03-06T14:49:00.08629485Z
Data,
  {"message": "Hello from Knative Eventing!"}

--profile serverless

./out/mapt aws openshift-snc create \
    --project-name jmorenas-snc-test \
    --backed-url file:///tmp/mapt-workspace \
    --version 4.21.0 \
    --pull-secret-file <pull-secret> \
    --conn-details-output /tmp/snc \
    --spot --tags owner=jmorenas \
    --profile serverless

Both outputs reported ready:

knativeEventingReady  : "ready"
knativeServingReady   : "ready"

Operator installed once (single namespace, OperatorGroup, Subscription), both CRs created in parallel. 44 resources total (vs 42 for a single CR profile — the extra 2 are the additional namespace + CR).

[adrianriobo]

Eventually I would suggest to create a profiles module inside of target/service/snc/profile and add all of them there...

[adrianriobo]

What is this for?

[jangel97]

This writes the kubeconfig to disk before profile deployment begins. If a profile fails (for example due to an operator timeout), the Pulumi stack returns an error and Results() is never called, so the kubeconfig would otherwise be lost. Writing it early ensures the user can still access the cluster to debug the failure.

[adrianriobo]

There is some logic when flag --disable-readiness is used, can not be reused?

[jangel97]

Good point, just removed the early write. Profile failure is now non-fatal (logged as a warning), so the stack completes and kubeconfig gets written through the existing Results() path, same as with --disable-readiness.