FAQ¶

General¶

What does "oooi" stand for?¶

OpenShift on OpenShift Infra. It provides the DHCP, DNS, and proxy services needed when one OpenShift cluster hosts another on an isolated VLAN.

Does oooi create hosted clusters?¶

No. oooi consumes an existing HostedCluster and NodePool; it provisions the network infrastructure the cluster needs. Create those resources with hcp or your own manifests, then apply an Infra and an InfraClusterAttachment.

Does oooi terminate TLS?¶

Never. The Envoy proxy routes by SNI and forwards encrypted bytes. Certificates stay inside the hosted cluster.

Why not use hosting-cluster Routes for everything?¶

You can — but tenant traffic then traverses hosting-cluster ingress, breaking the isolation that motivated isolated VLANs in the first place. oooi keeps the only cross-network paths narrow: specific SNI names to specific Services.

Networking¶

Can I run my own DHCP server alongside oooi?¶

Not on the same L2. Competing DHCP authorities cause non-deterministic worker bootstrapping. oooi must be the only DHCP server on the VLAN.

What if I omit internalProxyService?¶

The pod-network DNS view publishes no static HCP answers. Management pods can't resolve hosted endpoints by name — a valid hardening choice.

Which MetalLB modes are supported for apps ingress?¶

L2 advertisement (default configuration created by oooi). BGP and dual-stack are untested with this flow; validate separately before relying on them.

Can OAuth use LoadBalancer publishing directly?¶

For the KubeVirt configuration documented here, use the Route publishing strategy and expose OAuth through the proxy external Service when public access is required. spec.services is immutable after HostedCluster creation. See: Public DNS and OAuth publishing.

Yes. Create one Infra for the network and one InfraClusterAttachment per hosted cluster; oooi aggregates every attachment's DNS records and SNI backends onto a single DHCP/DNS/proxy stack. See Multiple hosted clusters on one VLAN.

How does the proxy route kubernetes.default.svc on a shared VLAN?¶

The shared DNS server maps kubernetes, kubernetes.default, kubernetes.default.svc, and kubernetes.default.svc.cluster.local to the shared proxy address. For KubeVirt attachments, the Infra controller discovers worker addresses through HyperShift NodePools and CAPI Machines, filters them to the Infra CIDR, and gives Envoy one /32 source range per worker. The hostname-SNI path uses port 443; the IP-based Kubernetes Service path uses port 6443 without SNI. In both cases, the matching source range selects the attachment's kube-apiserver Service.

The aliases are omitted while Machine addresses are unavailable, and a source address claimed by multiple attachments disables only the ambiguous alias routes. Fully qualified api.<cluster>.<domain> names remain the preferred bootstrap path. Source ranges are routing selectors, not authentication; VLAN anti-spoofing is still required for tenant isolation.

Operations¶

How do I know everything is healthy?¶

kubectl -n clusters get infra <name>

plus the applicable-path checks in Verification.

What happens when I delete Infra?¶

Its owned child CRs, Deployments, Services, ConfigMaps, ServiceAccounts, and component RoleBindings are garbage-collected. Delete each InfraClusterAttachment first to remove its hosted-cluster apps-ingress resources and cross-namespace control-plane NetworkPolicy. Cluster-scoped DHCP reader RBAC also needs a cleanup check. The HostedCluster itself is untouched until you delete it separately.

Where do public DNS records come from?¶

From your ExternalDNS instances watching the appropriate Services. oooi only attaches the labels/annotations those integrations need. See the ownership matrix.

Is there a validating webhook?¶

Not currently. Schema-required and pattern-invalid fields are still rejected by the CRD; runtime configuration problems surface through status conditions and messages instead.