Skip to content

MGMT-21787: Update prompt to include platform integration #218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-bot merged 1 commit into from
Sep 29, 2025
Merged

MGMT-21787: Update prompt to include platform integration #218

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions template.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -272,6 +272,7 @@ objects:
* Proactively offer the next steps based on the cluster type:
* **For a multi-node cluster:** Inform the user that roles can be automatically assigned or they can manually assign them. Offer to help with **manual role assignment** to a specific host (e.g., master, worker).
* **For a Single Node OpenShift (SNO) cluster:** Inform the user that the host is automatically assigned the `master` role and no further manual role assignment is needed. Propose the next logical step, such as initiating the installation.
* **For a cluster with platform oci:** Inform the user that the hosts will need to be manually assigned. Offer to help with **manual role assignment** to a specific host (e.g., master, worker).
* If the user wants to monitor host-specific issues, offer to retrieve **host events**.
* Different cluster types and host roles have different hardware requirements:
* For a multi-node cluster:
Expand All @@ -291,7 +292,9 @@ objects:

4. **Cluster Configuration (VIPs, Operators):**
* Before installation, the user might need to **set API and Ingress VIPs**. Only offer this for multi-node clusters with user-managed networking disabled, and only after hosts have been discovered (post-ISO boot) so that hosts' subnets are known.
* Clusters with platform baremetal, vsphere, or nutanix need to **set API and Ingress VIPs**.
* Single node clusters don't need to **set API and Ingress VIPs**.
* Clusters with platform none or oci don't need to **set API and Ingress VIPs**.
* Cluster with user-managed networking enabled don't need to **set API and Ingress VIPs**.
* Offer to **list available operators** and **add specific operator bundles** to the cluster if the user expresses interest in additional features.
Comment on lines +295 to 299
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

🧩 Analysis chain

Clarify VIP requirements by platform; current bullets can mislead.

As written, readers may infer unconditional VIP requirements/exemptions by platform. In Assisted Installer, VIPs are tied primarily to multi‑node + user‑managed‑networking (UMN) being disabled. Please fold platform nuances under that gating to avoid contradictions.

Apply this refinement:

       * Before installation, the user might need to **set API and Ingress VIPs**. Only offer this for multi-node clusters with user-managed networking disabled, and only after hosts have been discovered (post-ISO boot) so that hosts' subnets are known.
-      * Clusters with platform baremetal, vsphere, or nutanix need to **set API and Ingress VIPs**.
-      * Single node clusters don't need to **set API and Ingress VIPs**.
-      * Clusters with platform none or oci don't need to **set API and Ingress VIPs**.
-      * Cluster with user-managed networking enabled don't need to **set API and Ingress VIPs**.
+      * Platform nuances:
+        * baremetal, vsphere, nutanix: VIPs required when UMN is disabled; when UMN is enabled, do not set VIPs.
+        * none: do not set VIPs (rely on external/manual load balancing).
+        * oci: do not set VIPs (rely on cloud load balancers if applicable).
+      * Single node clusters don't need to **set API and Ingress VIPs**.
+      * Clusters with user-managed networking enabled don't need to **set API and Ingress VIPs**.

To confirm the exact OCI/None behaviors in Assisted Installer, please verify with upstream docs/releases:

🌐 Web query:

OpenShift Assisted Installer VIP requirements by platform (baremetal, vSphere, Nutanix, None, OCI) and user-managed networking

💡 Result:

Summary — VIP requirements (Assisted Installer / OpenShift 4.x)

  • General (cluster-managed networking, default): you must provide two VIPs in the machine network: API VIP (api..<base_domain>) and Ingress VIP (*.apps..<base_domain>). VIPs must be IPv4 when using dual‑stack (IPv4 primary). VIPs must belong to the machine CIDR and be reachable. [1][2][3]

  • User‑managed networking: the Assisted API expects you to supply the load‑balancer IP(s) instead of relying on keepalived/VRRP. Set user_managed_networking=true (and load_balancer.type=user‑managed) and specify api_vips and ingress_vips (they may both point to the same external LB IP if your LB uses a single VIP). VIP DHCP allocation is available but limited and not supported for newer SDN/OVN changes. [4][1]

  • Bare metal (Assisted IPI/UPI): requires API and Ingress VIPs for cluster‑managed networking (or the external LB IPs when user‑managed). If using VIP DHCP allocation, ensure SDN constraints apply. Keep ports 6443 (API) and 443 (console) reachable. [2][5]

  • vSphere (Assisted): same VIP rules as bare metal — provide API + Ingress VIPs (or external LB IPs with user‑managed networking). vSphere platform integration is supported by the Assisted Installer. [6][2]

  • Nutanix (Assisted): same VIP rules — supply API + Ingress VIPs (or external LB IPs if user‑managed). Nutanix is a supported platform for the Assisted Installer. [2][6]

  • OCI (Oracle Cloud Infrastructure): Assisted Installer support for OCI is available only with user‑managed networking (use an external load balancer / provide LB VIPs). You must supply the external LB IP(s) via api_vips/ingress_vips and enable user_managed_networking. [7][2]

Notes / links

  • API/Ingress VIP JSON fields and examples, dual‑stack rules, and vip_dhcp_allocation details: Red Hat Assisted Installer docs. [1][4]
  • Machine‑CIDR / validation rules, cluster vs. user‑managed networking behavior and validations. [3][5]

Sources
[1] Red Hat — Assisted Installer (VIPs, JSON examples & vip_dhcp_allocation).
[2] OpenShift docs — Installing with the Assisted Installer (networking, VIP requirements).
[3] OpenShift installer UPI docs (load balancer ports/requirements).
[4] Assisted Installer guide — configuring user‑managed load balancer and api_vips/ingress_vips.
[5] Assisted Installer validations (api/ingress VIP validations, machine CIDR).
[6] Assisted Installer platform pages (vSphere, Nutanix support).
[7] Notes on OCI support requiring user‑managed networking.

If you want, I can extract the exact JSON snippets and example CLI/API payloads for each platform (and indicate whether API+Ingress can be the same IP for your LB).

Clarify VIP requirements: gate by networking mode and node-count, not just platform

File: template.yaml Lines: 283-287

  • VIPs are determined by node-count + networking mode, not only by platform: for multi-node clusters with cluster-managed networking (default) require API + Ingress VIPs in the machine CIDR and reachable; prompt for them only after hosts are discovered (post‑ISO) so subnets are known.
  • If user_managed_networking=true the Assisted API expects external load‑balancer IP(s) — set api_vips/ingress_vips (may be the same IP). OCI is supported only with user‑managed networking and requires external LB IPs.
  • Platform mapping: baremetal / vSphere / Nutanix follow the above (VIPs for cluster‑managed; external LB IPs when UMN). platform "none" relies on external/manual load balancing (supply external LB IPs). Single‑node clusters do not need VIPs.
🤖 Prompt for AI Agents 
template.yaml lines 283-287: update the VIP guidance to gate requirements by
node-count and networking mode (user_managed_networking) rather than by platform
alone; explicitly state that multi-node clusters with cluster-managed networking
require API and Ingress VIPs in the machine CIDR and reachable (prompt for them
after hosts are discovered/post-ISO when subnets are known), that
user_managed_networking=true requires external load-balancer IPs set via
api_vips/ingress_vips (can be same IP) and that OCI supports only user-managed
networking with external LB IPs, that baremetal/vSphere/Nutanix follow the
node-count + networking-mode rules, platform "none" relies on external/manual
load balancing (supply external LB IPs), and single-node clusters do not need
VIPs.


Expand Down