# overlays/vr1-dc1-vips.yaml
# Per-DC VIP overlay for vr1-dc1 (the runbook's "DC2"). D-135 amendment /
# phase-4 Step 4: bundle.yaml hardcodes the API VIPs in vr1-dc0's bands, so
# deploying vr1-dc1 re-homes them into ITS bands. Base bundle stays the vr1-dc0
# source of truth; this overlay is applied only for the dc1 deploy:
#   juju deploy ./bundle.yaml --overlay ./overlays/vr1-dc1-vips.yaml
#
# Mapping (MEASURED from scripts/lib-net.sh lib_net_select_dc vr1-dc1, PLANE_NAME):
#   provider-public 10.12.4  -> 10.12.64   metal-admin 10.12.8 -> 10.12.68
#   metal-internal  10.12.12 -> 10.12.72   (host octets .50-.60 UNCHANGED)
# The three VIPs per service are public / admin / internal API endpoints
# (D-101 inherits the family layout; only the network prefix moves per DC).
applications:
  keystone:
    options:
      vip: "10.12.64.50 10.12.68.50 10.12.72.50"
  barbican:
    options:
      vip: "10.12.64.51 10.12.68.51 10.12.72.51"
  cinder:
    options:
      vip: "10.12.64.52 10.12.68.52 10.12.72.52"
  glance:
    options:
      vip: "10.12.64.53 10.12.68.53 10.12.72.53"
  magnum:
    options:
      vip: "10.12.64.54 10.12.68.54 10.12.72.54"
  neutron-api:
    options:
      vip: "10.12.64.55 10.12.68.55 10.12.72.55"
  nova-cloud-controller:
    options:
      vip: "10.12.64.56 10.12.68.56 10.12.72.56"
  octavia:
    options:
      vip: "10.12.64.57 10.12.68.57 10.12.72.57"
  openstack-dashboard:
    options:
      vip: "10.12.64.58 10.12.68.58 10.12.72.58"
  placement:
    options:
      vip: "10.12.64.59 10.12.68.59 10.12.72.59"
  ceph-radosgw:
    options:
      vip: "10.12.64.60 10.12.68.60 10.12.72.60"