How to Use: OCP Pod / KubeVirt Inventory

The OCP Pod / KubeVirt Inventory tool turns the Red Hat OpenShift Telco Application Onboarding Checklist into an online form. Instead of filling in a spreadsheet by hand, application teams fill in the form for each container Pod or KubeVirt VM they need, the tool keeps a running inventory table, and it can total up compute, network and storage requirements across every environment (DEV, SIT, UAT, PROD) so infra teams can plan capacity before deployment.

The form is organized into the same 7 sections as the original checklist:

• 1. General Application Information — environment, namespace, app name, Pod vs KubeVirt VM, replica count, owner contact.
• 2. Workload Specifications & Images — container image / pull secret for Pods, or guest OS / boot source / disk size for KubeVirt VMs. Only the relevant half of this section appears, based on your Workload Type selection in Section 1. If you set KubeVirt Guest OS Type to “Other”, a free-text field appears so you can specify the exact OS and version.
• 3. Compute & Real-Time Performance — CPU/memory requests and limits, CPU pinning, hugepages.
• 4. Primary Network — ingress/route exposure, TLS termination, listening port.
• 5. Secondary Networking (Multus) — SR-IOV/MACVLAN attachments, VLAN, IPAM. This whole block only appears if you answer “Yes” to Secondary Network Required.
• 6. Storage Persistence — appears only if Persistent Storage Required is “Yes”. Choose a Storage Provider Type: OpenShift ODF / Ceph (pick the ODF StorageClass) or Third Party Storage System (enter the storage brand & model, protocol, and third-party StorageClass name for arrays certified with CSI and OpenShift Virtualization). Access mode and requested capacity / PV volume size apply to either choice.
• 7. Security Constraints — Security Context Constraint, kernel capabilities, ConfigMaps, secrets, env vars.

Fields marked with a red * are mandatory. Some fields only appear once a related field is answered — e.g. Section 5 stays hidden until you set Secondary Network Required? to Yes. When you click Add to Inventory, the tool validates only the fields that are currently visible and required.

Click ➕ Add to Inventory to save the entry to the table below the form, then reset the form and repeat for the next Pod or VM — for the same application or a different one. There is no limit to how many entries you can add, and they can mix environments and workload types freely.

In the Inventory List table, use Edit to reopen an entry in the form (its section fields and visibility are restored automatically), Duplicate to insert a copy of that row right below it (handy for similar Pods/VMs that only differ in a few fields — the copy opens straight into Edit mode so you can adjust it), or Delete to remove it. 🗑 Clear All in the top bar wipes the entire inventory — use it with care.

Once you have at least one entry, click 📊 Generate Summary. This produces:

• Top-level tiles: total applications, total workload entries, total Pods to deploy, total KubeVirt VMs, and total CPU / memory / storage / primary & secondary NICs across the whole inventory.
• A category table broken down by Environment × Workload Type — e.g. PROD (Pod), PROD (KubeVirt), UAT (Pod), UAT (KubeVirt) — each with its own workload count, replica count, CPU, memory, storage, NIC and hugepages totals, plus a grand total row.

Replica count is applied automatically: an entry with 3 replicas contributes 3× its CPU, memory, storage and NIC requirements to the totals.

Each row in the Inventory List has a checkbox (the header checkbox selects/deselects all rows). Click 🧾 Generate YAML to turn the checked rows into a base set of OpenShift/KubeVirt manifests: one .yaml file per row if you selected one row, or a .zip of one file per row if you selected several.

Depending on the entry, each file can include:

• A Namespace, and either a Deployment (Container Pod) or a VirtualMachine plus, if the boot source is a qcow2 URL, a DataVolume (KubeVirt).
• A Service, and a Route if External Access is Yes, with TLS termination matching your 4.3 selection.
• A PersistentVolumeClaim if Persistent Storage is Yes, using whichever StorageClass your 6.1a choice points to (ODF or third-party).
• For Pods: a ConfigMap and Secret TEMPLATE for anything listed in 7.3/7.4 — these hold placeholder content/values you must fill in yourself; the tool never invents real secret data.
• A RoleBinding granting the default ServiceAccount your chosen SCC, if it's anything other than the default restricted-v2.
• If Secondary Network is Yes: a NetworkAttachmentDefinition TEMPLATE for SR-IOV/ MACVLAN CNI types (OVN Secondary gets a note instead, since it has no standard NAD shape).

This is intentionally a base configuration, not a finished one: any <PLACEHOLDER> text or # TODO comment marks something the form couldn't know (a real image digest, actual secret values, the exact NAD your network team provisions) and needs review before you apply it. Note also that a Deployment's ReplicaSet is intentionally not generated as a separate file — it's created and owned automatically by the Deployment itself.

• 💾 Save (Excel) downloads an .xlsx file with two sheets: a Summary sheet (the category breakdown and grand totals) and an Inventory sheet (one row per Pod/KubeVirt entry, with every checklist parameter as its own column). Keep this file — it's your record and your backup.
• 📂 Open File lets you reload a previously saved inventory .xlsx. It reads the Inventory sheet and rebuilds the whole table, so you can pick up exactly where you left off, hand the file to a colleague to continue, or merge it back in later.

The tool also keeps a local autosave in your browser between visits, but the Excel file is the portable, shareable copy — use Save regularly.

• Set Workload Type first — it determines which fields in Section 2 you need to fill in.
• For latency-sensitive Telco workloads (DPDK/VNF), remember to set Dedicated CPU Pinning and Hugepages Allocation Size in Section 3.
• If an application needs multiple Pods with different specs (e.g. a control-plane Pod and a data-plane Pod), add them as separate entries under the same Application Name / Namespace.
• Re-run Generate Summary any time after adding, editing or deleting entries — it always reflects the current inventory table.