dc: vr1-dc1
output: overlays/vr1-dc1-vips.yaml
family: v4
legs:
- provider-public
- metal-admin
- metal-internal
prefixes_v4:
  provider-public: 10.12.64
  metal-admin: 10.12.68
  metal-internal: 10.12.72
apps:
- name: keystone
  octet: 50
- name: barbican
  octet: 51
- name: cinder
  octet: 52
- name: glance
  octet: 53
- name: magnum
  octet: 54
- name: neutron-api
  octet: 55
- name: nova-cloud-controller
  octet: 56
- name: octavia
  octet: 57
- name: openstack-dashboard
  octet: 58
- name: placement
  octet: 59
- name: ceph-radosgw
  octet: 60
header: '# 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).

  '