Please help re assign to correct component if it don't look right.

I followed the steps in https://access.redhat.com/documentation/en-us/openshift_container_platform/4.2/html/serverless_applications/installing-openshift-serverless but still can't get a successful Knative running

$ oc get knativeserving/knative-serving -n knative-serving -o yaml
apiVersion: serving.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"serving.knative.dev/v1alpha1","kind":"KnativeServing","metadata":{"annotations":{},"name":"knative-serving","namespace":"knative-serving"}}
  creationTimestamp: "2020-01-13T03:17:30Z"
  finalizers:
  - knative-serving
  generation: 2
  name: knative-serving
  namespace: knative-serving
  resourceVersion: "59666"
  selfLink: /apis/serving.knative.dev/v1alpha1/namespaces/knative-serving/knativeservings/knative-serving
  uid: f75509a6-7ddd-41fd-a7b7-94ecfc180f52
spec: {}
status:
  conditions:
  - lastTransitionTime: "2020-01-13T03:17:30Z"
    status: Unknown
    type: DependenciesInstalled
  - lastTransitionTime: "2020-01-13T03:17:30Z"
    status: Unknown
    type: DeploymentsAvailable
  - lastTransitionTime: "2020-01-13T03:17:32Z"
    message: 'Install in progress: SMCP not yet ready'
    reason: NotReady
    status: "False"
    type: InstallSucceeded
  - lastTransitionTime: "2020-01-13T03:17:32Z"
    message: 'Install in progress: SMCP not yet ready'
    reason: NotReady
    status: "False"
    type: Ready

We have seen the same condition here, "Install in progress: SMCP not yet ready".

It's not clear what SMCP is, or how we can cause it to be ready.

"SMCP" is short for "ServiceMeshControlPlane". We're in the process of removing our direct dependency on this particular component. Otherwise, I'd create an issue for us to expand that acronym to its full form.

What the error is telling you is that for some reason the ServiceMeshControlPlane we're installing to handle traffic for Knative is not yet ready. To diagnose this, you'd want to `oc describe smcp -n knative-serving-ingress`. If you include the output of that here, I'm happy to help diagnose. In the status block we should be able to determine which Service Mesh component is not yet ready and hopefully why.

Sorry for late response, here's the requested info

[yapei@localhost test-files]$ oc get knativeserving/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'
DependenciesInstalled=Unknown
DeploymentsAvailable=Unknown
InstallSucceeded=False
Ready=False
[yapei@localhost test-files]$ oc describe knativeserving/knative-serving -n knative-serving
Name:         knative-serving
Namespace:    knative-serving
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"serving.knative.dev/v1alpha1","kind":"KnativeServing","metadata":{"annotations":{},"name":"knative-serving","namespace":"kn...
API Version:  serving.knative.dev/v1alpha1
Kind:         KnativeServing
Metadata:
  Creation Timestamp:  2020-02-04T10:29:15Z
  Finalizers:
    knative-serving
  Generation:        2
  Resource Version:  632140
  Self Link:         /apis/serving.knative.dev/v1alpha1/namespaces/knative-serving/knativeservings/knative-serving
  UID:               1a5a35f5-7824-46cc-a939-d7d4c346b926
Spec:
Status:
  Conditions:
    Last Transition Time:  2020-02-04T10:29:15Z
    Status:                Unknown
    Type:                  DependenciesInstalled
    Last Transition Time:  2020-02-04T10:29:15Z
    Status:                Unknown
    Type:                  DeploymentsAvailable
    Last Transition Time:  2020-02-04T10:29:17Z
    Message:               Install in progress: SMCP not yet ready
    Reason:                NotReady
    Status:                False
    Type:                  InstallSucceeded
    Last Transition Time:  2020-02-04T10:29:17Z
    Message:               Install in progress: SMCP not yet ready
    Reason:                NotReady
    Status:                False
    Type:                  Ready
Events:                    <none>
[yapei@localhost test-files]$ oc describe smcp -n knative-serving-ingress
Name:         basic-install
Namespace:    knative-serving-ingress
Labels:       serving.knative.openshift.io/ownerName=knative-serving
              serving.knative.openshift.io/ownerNamespace=knative-serving
Annotations:  manifestival: new
API Version:  maistra.io/v1
Kind:         ServiceMeshControlPlane
Metadata:
  Creation Timestamp:  2020-02-04T10:29:16Z
  Finalizers:
    maistra.io/istio-operator
  Generation:        1
  Resource Version:  632091
  Self Link:         /apis/maistra.io/v1/namespaces/knative-serving-ingress/servicemeshcontrolplanes/basic-install
  UID:               ded560b1-cbc7-4ba3-b06d-9aedd8153f17
Spec:
  Istio:
    Gateways:
      Cluster - Local - Gateway:
        Autoscale Enabled:  false
        Enabled:            true
        Labels:
          App:                        cluster-local-gateway
          Istio:                      cluster-local-gateway
          Maistra - Control - Plane:  knative-serving-ingress
        Ports:
          Name:         status-port
          Port:         15020
          Name:         http2
          Port:         80
          Target Port:  8080
          Name:         https
          Port:         443
      Istio - Egressgateway:
        Enabled:  false
      Istio - Ingressgateway:
        Autoscale Enabled:  false
        Labels:
          Maistra - Control - Plane:  knative-serving-ingress
        Type:                         LoadBalancer
    Global:
      Default Pod Disruption Budget:
        Enabled:                         false
      Disable Policy Checks:             false
      Multitenant:                       true
      Omit Sidecar Injector Config Map:  true
      Proxy:
        Auto Inject:  disabled
    Grafana:
      Enabled:  false
    istio_cni:
      Enabled:  true
    Kiali:
      Enabled:  false
    Mixer:
      Enabled:  false
      Policy:
        Enabled:  false
      Telemetry:
        Enabled:  false
    Pilot:
      Autoscale Enabled:  false
      Sidecar:            false
    Prometheus:
      Enabled:  false
    Sidecar Injector Webhook:
      Enabled:  false
    Tracing:
      Enabled:  false
Status:
  Components:  <nil>
  Conditions:
    Last Transition Time:  2020-02-04T10:29:16Z
    Message:               Installing mesh generation 1.0.6-1.el8-1
    Reason:                ResourceCreated
    Status:                False
    Type:                  Installed
    Last Transition Time:  2020-02-04T10:29:16Z
    Message:               Installing mesh generation 1.0.6-1.el8-1
    Reason:                ResourceCreated
    Status:                False
    Type:                  Reconciled
    Last Transition Time:  2020-02-04T10:29:16Z
    Message:               Installing mesh generation 1.0.6-1.el8-1
    Reason:                ResourceCreated
    Status:                False
    Type:                  Ready
  Last Applied Configuration:
Events:
  Type     Reason      Age                From                                Message
  ----     ------      ----               ----                                -------
  Normal   Installing  100s               servicemeshcontrolplane-controller  Installing mesh generation 1.0.6-1.el8-1
  Warning  Installing  6s (x14 over 57s)  servicemeshcontrolplane-controller  Error processing component security: error: no matches for kind "Deployment" in version "extensions/v1beta1"

There is a known bug where Service Mesh does not yet work in OCP 4.4 builds and fails with the `error: no matches for kind "Deployment" in version "extensions/v1beta1"` error you've shown above. However, this is a 4.3 cluster you're testing this with? This API should not be disabled in 4.3 and we have continuous integration tests that run against OpenShift 4.3 and do not see this error.

If this is something newer than an OCP 4.3 release, then it's a known issue. If it's a 4.3 release then we have an unknown issue that needs to be tracked down.

This is tested against 4.4 cluster, thanks for your response.

Do we have bug tracking the known issue on 4.4, can I use this bz to track it or shall I close it ? Let me know what should I do

We have two JIRA issues tracking this currently - one for OpenShift Serverless and one for Service Mesh. The underlying issue is in Service Mesh, but since Serverless depends on Service Mesh we created issues for both.

Serverless - https://issues.redhat.com/browse/SRVKS-382

Service Mesh - https://issues.redhat.com/browse/MAISTRA-1078

Closing as addressed in OpenShift Serverless 1.5.0 - https://issues.redhat.com/browse/SRVKS-382
Service Mesh issue addressed in https://issues.redhat.com/browse/MAISTRA-1078