juju occasionally switches a units public-address if an additional interface is added post-deployment
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
High
|
Michael Foord | ||
1.24 |
Fix Released
|
High
|
Michael Foord | ||
1.25 |
Fix Released
|
High
|
Michael Foord |
Bug Description
If an additional port is added to a guest then the juju public-address of that unit will occasionally change which breaks some of the Openstack teams tests (see below). It would be good if public-address didn't flip like this.
In the below example additional nics were added to neutron-gateway/0 and neutron-gateway/1. The ip of neutron-gateway/0 flipped but neutron-gateway/1 did not.
$ juju status neutron-gateway
environment: lytrusty
machines:
"11":
agent-state: started
agent-version: 1.23-beta1.1
dns-name: 10.5.21.19
instance-id: f9b14208-
instance-state: ACTIVE
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=1536M root-disk=10240M availability-
"12":
agent-state: started
agent-version: 1.23-beta1.1
dns-name: 10.5.21.10
instance-id: 67b917f1-
instance-state: ACTIVE
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=1536M root-disk=10240M availability-
services:
neutron-gateway:
charm: local:trusty/
exposed: false
relations:
amqp:
- rabbitmq-server
cluster:
- neutron-gateway
neutron-
- neutron-api
quantum-
- nova-cloud-
shared-db:
- mysql
units:
neutron-
machine: "11"
neutron-
machine: "12"
$ nova list | grep -E '\-(11|12)'
| f9b14208-
| 67b917f1-
neutron-gateway/0 is still up and running but since it has switched to an ip which doesn't have the hosts services listening on it juju cmds fail:
$ juju ssh neutron-gateway/0 "uname -n"
ERROR subprocess encountered error code 1
ssh_exchange_
ERROR subprocess encountered error code 255
$ juju ssh neutron-gateway/1 "uname -n"
juju-lytrusty-
Connection to 10.5.21.10 closed.
$ ssh 10.5.21.9 "uname -n"
juju-lytrusty-
Why does this matter? The Openstack teams CI tests sometime break because the neutron-gateway guest becomes inaccessible by juju {run,ssh}. The reason for this is that during the post depoloyment network setup an additional nic (eth1) is added to the guest. The additional nic is on the same network as eth0 but acts as an external port and cannot be directly contacted for guest access.
Changed in juju-core: | |
importance: | Undecided → High |
status: | New → Triaged |
tags: | added: network |
Changed in juju-core: | |
milestone: | none → 1.24-alpha1 |
Changed in juju-core: | |
milestone: | 1.24-alpha1 → 1.25.0 |
tags: | added: addressability openstack-provider |
tags: | added: bug-squad |
Changed in juju-core: | |
assignee: | nobody → Michael Foord (mfoord) |
Changed in juju-core: | |
milestone: | 1.25-alpha1 → 1.25-beta1 |
Changed in juju-core: | |
status: | Triaged → In Progress |
Changed in juju-core: | |
milestone: | 1.25-beta1 → 1.25-beta2 |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core: | |
milestone: | 1.25-beta2 → 1.26-alpha1 |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
tags: | added: sts |
I believe I've seen this on multiple versions of juju but the one the debug was taken from above was 1.23-beta1- trusty- amd64. The environment type was openstack.
I'll attach logs from the bootstrap node and from neutron-gateway/0