Two ideas how to achieve it:

We're shipping several RPMs with optional components. They're handled by the kustomizer component. While some resources (like huge CRDs) might not be ready immediately after `oc apply -k .`, we can be pretty sure that namespaces will be created asap.

If there's any problem with kustomizer's flow, it'll emit an error which stops the start up of the MicroShift. In other words: if the microshift.service is ready, it means that kustomizer applied all resources to the api server.

Based on that assumption, if we scan namespaces after microshift is ready, we can check if microshift's optional RPMs are deployed. In case they're, we can wait for the workloads in these namespaces (we know them, because we own the manifests).

Another approach is to scan the manifests on disk, use kustomize API to iterate over them and gather deploys, ds and sts.

For workloads that are created by operators (e.g. vg-manager or istiod), we could look for annotation that would instruct healthcheck to watch more resources for readiness. We could reuse existing --custom arg syntax, for example:

metadata:
  annotations:
    healthcheck.microshift.io: '{"NAMESPACE":{"deployments":["NAME"]}}' 

So Istio CR for gateway API would look like:

apiVersion: sailoperator.io/v1alpha1
kind: Istio
metadata:
  name: openshift-gateway-api
  annotations:
    healthcheck.microshift.io: '{"openshift-gateway-api": {"deployments": ["istiod-openshift-gateway-api"]}}'
...