juju 1/2 using MAAS 1.9/2 incorrectly reports the private address

[Darryl Weaver]

juju-core 1.25.0 and using a MAAS environment based on 1.9.0~beta2+bzr4456

juju reports the DNS name from the MAAS environment in juju status as the public-address, this would likely map to the PXE boot interface, usually the management network, for Openstack deployments.
But the IP address it picks for the private address is different and therefore not on the management network.

In a situation with multiple NICs on a node and some that may be in separate spaces in MAAS (i.e. cannot route between each other).
Then it is the case that the private address used by juju will matter, as it needs to be reachable from the bootstrap node.
This would usually be the management network on eth0.

In a test deployment with nodes in MAAS with multiple NICs, juju selected the address on eth1, not the PXE boot interface, eth0.
Networks used were:
192.168.92.0/24 - management network - always eth0
192.168.95.0/24 - public network
192.168.140.0/24 - data network
192.168.160.0/24 storage network

The private address reported on the nodes with multiple NICs were on the data network, 192.168.140.0/24

The most obvious symptom is that juju ssh does not work to nodes as it proxies through the bootstrap node that cannot reach the 192.168.140.0/24 network.

To re-create:
using MAAS 1.9-beta2
Create nodes in MAAS with at least 2 NICs in different spaces (i.e.. subnets are not routed to each other)
Bootstrap juju 1.25.0
Add a machine with 2 NICs using juju add-machine
Use juju ssh to try connecting to the machine.

Juju ssh will hang.

[Bilal Baqar (bbaqar)]

I am getting the DNS name instead of the IP in the public address running on juju 1.24.5 and maas 1.8.2.

But I am only getting it from the first of three units of my charms. So I am getting the DNS name in public-address field from relation-get when the peer relation changes with the first unit and getting IP when the relation changes with any other unit.

[Dimiter Naydenov (dimitern)]

This should be resolved for the 1.26.0 release, as juju does not yet support taking advantage of spaces in MAAS 1.9.

[Sandor Zeestraten (szeestraten)]

Hi, I think we are running into the same issue with nodes and multiple NICs using juju 2.0-beta11 and MAAS 2.0.0 (rc1+bzr5143) when deploying the openstack-base bundle.

We have a couple of network spaces defined in MAAS:
10.42.2.0/23 - admin/mgmt network
10.42.128.0/23 - public network

We want juju to use the admin/mgmt network, however the nodes with multiple NICs are getting their public-addresses from the public network (see output of juju status below).

What is the roadmap for this issue now that we're going towards 2.x and not 1.26.0?

$ juju status
MODEL CONTROLLER CLOUD VERSION
os-test prodjuju prodmaas 2.0-beta11

APP STATUS EXPOSED ORIGIN CHARM REV OS
ceph-mon active false jujucharms ceph-mon 1 ubuntu
ceph-osd active false jujucharms ceph-osd 2 ubuntu
ceph-radosgw active false jujucharms ceph-radosgw 3 ubuntu
cinder active false jujucharms cinder 1 ubuntu
cinder-ceph false jujucharms cinder-ceph 1 ubuntu
glance active false jujucharms glance 1 ubuntu
keystone active false jujucharms keystone 1 ubuntu
mysql active false jujucharms percona-cluster 1 ubuntu
neutron-api active false jujucharms neutron-api 1 ubuntu
neutron-gateway active false jujucharms neutron-gateway 1 ubuntu
neutron-openvswitch false jujucharms neutron-openvswitch 2 ubuntu
nova-cloud-controller active false jujucharms nova-cloud-controller 1 ubuntu
nova-compute active false jujucharms nova-compute 1 ubuntu
ntp false jujucharms ntp 0 ubuntu
openstack-dashboard active false jujucharms openstack-dashboard 1 ubuntu
rabbitmq-server active false jujucharms rabbitmq-server 3 ubuntu

RELATION PROVIDES CONSUMES TYPE
mon ceph-mon ceph-mon peer
mon ceph-mon ceph-osd regular
mon ceph-mon ceph-radosgw regular
ceph ceph-mon cinder-ceph regular
ceph ceph-mon glance regular
ceph ceph-mon nova-compute regular
cluster ceph-radosgw ceph-radosgw peer
identity-service ceph-radosgw keystone regular
cluster cinder cinder peer
storage-backend cinder cinder-ceph subordinate
image-service cinder glance regular
identity-service cinder keystone regular
shared-db cinder mysql ...

[Anastasia (anastasia-macmood)]

Removing 2.1 milestone as we will not be addressing this issue fully in 2.1.

[Sandor Zeestraten (szeestraten)]

@anastasia-macmood
Any update on this for 2.2 or 2.3?

[John A Meinel (jameinel)]

Sorry about the delay in response. We won't be addressing this specifically for 2.2. We're still trying to figure out how to concretely model things like Controller endpoints and 'ssh' access for machines and how it overlaps with spaces.

We have had both cases where people have asked specifically *for* the PXE network to be the one that gets used, and where people have aske for it *not* to be the one that it used. What we really need is a way for users to declare a space for us to use for things like access to machines.

It may be that we model this as a generic endpoint on all charms (like we currently have 'juju-info), but that doesn't really handle things like "juju add-machine" where you'd still like to declare the information about where 'ssh' should be accessed, but you don't have any applications running on that machine.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.