STAGE 5 -- dc0 bundle deploy ATTEMPT 1: FAILED on a bundle/overlay defect (2026-07-31)
======================================================================================
COMMAND (from the dc0 rack, D-138 client host):
juju deploy ./bundle.yaml --overlay ./overlays/vr1-dc0-vips.yaml \
--overlay ./overlays/vr1-dc0-machines.yaml --overlay ./overlays/vr1-dc0-octavia-pki.yaml
VERDICT:
ERROR cannot deploy bundle: cannot deploy application "barbican": unknown option "prefer-ipv6"
STATE AFTER THE FAILURE -- NOTHING IS HALF-APPLIED (measured, not assumed):
juju status -m vr1-dc0 -> Model "vr1-dc0" is empty. applications: 0 machines: 0
Juju validated the whole bundle and aborted atomically BEFORE creating anything.
THE DRY-RUN PASSED AND THE DEPLOY DID NOT. This is the load-bearing lesson:
'juju deploy --dry-run' resolved all 56 charms, planned 108 relations and exited 0.
It does NOT validate charm CONFIG OPTION NAMES against each charm's schema.
A green --dry-run is therefore NOT a gate on option validity.
ROOT CAUSE -- overlays/vr1-dc0-vips.yaml applies 'prefer-ipv6: true' to ALL 13 VIP apps
(R2, RULED 2026-07-27). MEASURED against CHARMHUB's own config-yaml at each pinned
channel -- the vendor schema, not a repo comment:
CHARM CHANNEL prefer-ipv6?
------ ------- ------------
barbican 2024.1/stable NO
ceph-radosgw squid/stable YES
cinder 2024.1/stable YES
designate 2024.1/stable NO
glance 2024.1/stable YES
keystone 2024.1/stable YES
magnum 2024.1/stable NO
neutron-api 2024.1/stable YES
nova-cloud-controller 2024.1/stable YES
octavia 2024.1/stable NO
openstack-dashboard 2024.1/stable YES
placement 2024.1/stable NO
vault 1.8/stable NO
SUPPORTED (7): ceph-radosgw cinder glance keystone neutron-api nova-cloud-controller openstack-dashboard
NOT SUPPORTED (6): barbican designate magnum octavia placement vault
IT WAS NEVER REMOVED -- IT WAS NEVER THERE. barbican at 2023.2/stable, 2023.1/stable and
ussuri/stable all return NO. So this is not an obsoleted option that newer charms dropped;
'prefer-ipv6' simply belongs to a SUBSET of the OpenStack charms. The R2 ruling's uniform
application was never valid for these six.
WHY IT MATTERS BEYOND THE ERROR -- provider-bundle-check INVARIANT 9 COUPLES THEM:
'prefer-ipv6 makes HAProxy bind :::port in ADDITION to *:port, so the two must travel
together.' (scripts/provider-bundle-check.py:30-33)
So for the six unsupported charms the open question is whether their v6 VIP legs can
function at all without the option, or whether HAProxy will never bind v6 for them.
That is a RULED-SURFACE question (R2) and is NOT decided here.
