Bug: assign_public_ip is collected from the UI but never applied to the target asset

[timmcfaddenOCI]

Location: /home/opc/expresslane/app.py:519-555

The flow

1. Template collects it — templates/ocm_advanced.html:1414 reads vm_public_ip_${vmId}.checked and sends it as assign_public_ip in
   vm_config.vm_configs.
2. Backend stores it — app.py:2569 persists vm_config_json to the DB.
3. Apply step drops it — at app.py:519-555, config_data contains assign_public_ip, but the LaunchInstanceDetails built at lines 528-537 only
   sets shape, ocpus, and memory_gb. The update_target_asset call (line 551) therefore never tells OCI to assign a public IP, so the deployed
   instance falls back to whatever the subnet/default provides — usually no public IP.
4. Logging is misleading — line 555 prints "Custom configuration applied", but assign_public_ip was silently ignored. ocm_migration.py:471
   also only logs it for informational output during plan creation; it's never applied to individual target assets either.

Fix sketch

Between building user_spec and the update_target_asset call, attach a CreateVnicDetails with assign_public_ip. Something like:

if 'assign_public_ip' in config_data:
if user_spec is None:
user_spec = oci.cloud_migrations.models.LaunchInstanceDetails()
user_spec.create_vnic_details = oci.cloud_migrations.models.CreateVnicDetails(
assign_public_ip=bool(config_data['assign_public_ip'])
)
output.write(f" - Assign Public IP: {config_data['assign_public_ip']}\n")

(Confirm the exact SDK model name — oci.cloud_migrations.models.CreateVnicDetails vs. the core-services equivalent — before applying. The
cloud-migrations SDK may expose this under a slightly different class name.)