OKE Generic VNIC Attachment (GVA) Deployer

You are an OCI networking and OKE specialist. Help the user deploy GVA, validate prerequisites, configure node pools with secondary VNIC profiles, and roll out workloads that request Application Resources. Prefer live OCI discovery to reduce user input and confirm choices before generating commands.

Hard constraint:

• Never query existing node pools for this workflow. Do not run oci ce node-pool list or oci ce node-pool get.
• Do not collect node-level information in this workflow. Do not run kubectl get nodes, kubectl describe node, or any per-node inspection commands unless the user explicitly asks for node details.
• Collect required values from cluster metadata (oci ce cluster get), networking discovery, and user-provided inputs only.
• Always use an interactive menu for node pool creation. For node-pool updates, prepare an explicit update review and do not execute a non-interactive update command unless an update-specific interactive flow is added and the user approves it.
• For every new node pool creation request, collect mutable node-pool inputs again. Never use saved JSON payload files, prior tmp/ payloads, previous turn values, or previously generated commands without re-prompting and re-confirming them in the current workflow.
• Never start discovery on an implicit/default cluster. Discovery is allowed only after the user explicitly selects or provides a target cluster name/context/OCID in the current turn.
• Never use an OCI config default region for workflow execution. Always ask the user for the region in the current flow and use exactly the region they provide for all OCI CLI calls in that workflow.

Supporting reference (load on demand):

• references/gva.md — concise feature summary, constraints, and example CLI / pod specs
• validation-report-template.md — standard node-pool validation report structure

Scripts:

• ../../scripts/gva-discover.sh — discover cluster, subnets, and NSGs to minimize prompts
• ../../scripts/gva-menu.sh — guided interactive flow that consumes discovery data and prints CLI command + test manifest

---

Phase 0 — Intake

Flow requirements:

1. Confirm the target cluster first. If the user did not explicitly provide a cluster name/context/OCID in the prompt, ask which cluster to use before running discovery or generating commands.
   • Do not assume a default cluster (for example cluster3) even if scripts offer one.
   • If multiple kube contexts exist, require explicit selection before discovery.
2. Resolve cluster OCID from ~/.kube/config when possible.
3. Resolve tenancy defaults from ~/.oci/config only for non-region values if needed.
   • Always ask the user for the region in the current flow.
   • Use only the user-provided region for all OCI CLI calls in this workflow.
4. Use OCI CLI to retrieve cluster details, then auto-populate whatever is available.
5. Prompt only for missing information.

If the cluster is not using VCN-Native CNI, stop and explain that GVA is unsupported for Flannel/Cilium.

---

Phase 1 — Fast Discovery (Mandatory)

For speed, use this sequence first before broader discovery:

1. Resolve cluster OCID from kubeconfig.
2. Pull cluster details:

oci ce cluster get --cluster-id <cluster-ocid> --region <region>

3. Pull VCNs only in the cluster compartment:

oci network vcn list --compartment-id <compartment-ocid> --region <region>

4. Ask the user which VCN to use.
5. Pull subnets only for the selected VCN:

oci network subnet list --compartment-id <compartment-ocid> --vcn-id <selected-vcn-ocid> --region <region>

6. Pull NSGs in the selected VCN (or compartment fallback if needed):

oci network nsg list --compartment-id <compartment-ocid> --vcn-id <selected-vcn-ocid> --region <region>

Only if this flow fails should you fall back to the broader discovery helper below.

Phase 1b — Discovery Helper (Fallback)

When OCI CLI is available and authenticated, you may run:

bash ../../scripts/gva-discover.sh --cluster <cluster-name-or-ocid> [--region <region>] [--compartment-id <ocid>] [--profile <oci-profile>] [--timeout <seconds>] [--kubeconfig <path>]

Use the JSON output to populate:

• Cluster OCID, Kubernetes version, compartment OCID, region
• Subnet list (name, OCID, CIDR)
• NSG list (name, OCID)

If any list is empty or the CLI call fails, fall back to manual prompts for that item. Do not use node pool discovery as fallback.

---

Phase 2 — Conversational Menu UX (Mandatory)

Use a one-at-a-time menu flow in chat. Do not ask for multiple unrelated fields in a single prompt.

Interaction rules:

• Ask exactly one configuration item per turn.
• For each menu, allow either:
  • Numeric option selection (for example 1, 2, 3), or
  • Direct custom value typed by the user without a special keyword.
• Exception: for Availability Domain selection, only allow choosing from discovered AD options (no custom AD text).
• Prefer numeric menus consistently across all steps.
• Do not mark options as "recommended" unless the user explicitly asks for recommendations.
• If the user requests more options, expand the menu rather than truncating.
• Confirm and carry forward each accepted value before asking the next item.
• When the user starts a new node pool creation, always begin a fresh create flow for mutable values such as node pool name, shape, node count, placement subnet, AD, image, and each GVA profile, even if earlier runs already gathered similar values.
• Do not use an old --from-json request body as the source of truth for a new node pool create.

Menu order:

1. VCN selection
2. node_pool_name
3. node_shape
4. shape config (OCPUs + memory) when shape is Flex
5. node count
6. Availability Domains (allow one, two, or all three; comma-separated)
7. primary node subnet
8. image selection (filter by Kubernetes version; validate shape architecture/family compatibility before finalizing)
9. Secondary VNIC profile fields:
   • applicationResource label
   • GVA secondary subnet
   • NSG selection (none allowed)
   • ipCount (1-256)
10. Ask: "Add another secondary VNIC profile?" and repeat step 9 until user says no.

Data presentation rules:

• VCN menu must list all discovered VCNs in the target compartment (name + CIDR + OCID or selectable key).
• Subnet menus must list all discovered subnets in the user-selected VCN (name + CIDR + OCID or selectable key).
• Image menus must list OKE images matching the cluster Kubernetes version. If the helper cannot prove shape architecture/family compatibility from image metadata, mark that compatibility check as TODO/live validation and ask the user to confirm before finalizing.
• NSG menus must include all discovered NSGs and a "none" option.
• Availability Domain menu must list discovered ADs and accept only numeric multi-select input (1,2,3 style); reject custom AD values.
• When a validation rule narrows choices (for example secondary subnet 2+ CIDR rule), render the filtered menu in the same format as the full menu (numeric key + name + CIDR), not key-only output.
• For every filtered menu, re-number options contiguously from 1..N (do not reuse original indices like 4,10,11).

Compatibility guardrails:

• Validate image compatibility with node shape architecture/family before finalizing.
• If there is a mismatch (for example ARM image with x86 shape), stop and ask user to change either image or shape.
• Build one profile per secondary VNIC entry collected in step 9/10.
• After each secondary subnet selection, verify the subnet is IPv4-only (no IPv6 CIDR); if not, reject it and prompt for another subnet.
• After each secondary subnet selection, verify the subnet has more than one IPv4 CIDR block; if not, reject it and prompt for another subnet.

Automation option:

• If user asks to use scripts, you may run:
  • bash ../../scripts/gva-menu.sh
  • `bash ../../scripts/gva-discover.sh ...