Comment 34 for bug 1603473

Hey Mike- let's have a call . Please contact me on my cell # below. I can set you up on our vpn but let's go over one-on-one.
Thanks,
John

John Casey
Founder/CTO
CPLANE NETWORKS
Applications, say hello to your new network!TM
Direct: 415-215-0854
Skype: johnacasey
<email address hidden>
www.cplanenetworks.com
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Mick Gregg
Sent: Monday, July 25, 2016 7:43 AM
To: John Casey
Subject: [Bug 1603473] Re: Relation fails as untis/machines are on different subnet on a multi NIC setup, juju 2.0 beta11

@g-john-p

Yes, please, if you can give me access to your system, I'm keen to take a look.

I'll contact you by email.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1603473

Title:
  Relation fails as untis/machines are on different subnet on a multi
  NIC setup, juju 2.0 beta11

Status in juju-core:
  Incomplete

Bug description:
  On a multi NIC setup, we notice with Juju 2.0 beta11 and MAAS 1.9, some machines' preferred private addresses are not the IP address provisioned and provided by MAAS but the one from a second NIC where we set the IP manually for SSH remote access. The machines and the containers have a valid IP from both subnets, but when the relation is established between the nova compute and the nova cloud controller, it performs certain reverse DNS operation and it gives the error: http://paste.ubuntu.com/19349672/
  With Juju 2.0 beta5, this did not happen.

  Setup details:
  As the charm is still be worked on, I had attached the yaml file to deploy the charms of openstack bundle only, and the yaml file is attached to this bug.
  Note: here we are not using the neutron-gateway and few other nodes from openstack(Which our charm will take care of).

  With Juju 2.0 beta11:
  MAAS (Running in a VM in Virtual machine manager)
                  Version 1.9
                  eth0: 10.10.11.152(Unmanaged)
                  eth1: 10.9.1.10(Managed)

  JUJU (in a VM in Virtual machine manager)
                  Version 2.0 beta11
                  eth0: 10.10.11.151
                  eth1: 10.9.1.151
                  DNS: 10.9.1.10
    .local/share/juju/controller.yaml file content
        cplane-controller:
      unresolved-api-endpoints: ['10.9.1.160:17070', '10.10.11.140:17070']
      uuid: 1a5c7aba-18ad-457b-8bb6-7aa6feb6e1cf
      api-endpoints: ['10.9.1.160:17070', '10.10.11.140:17070']

  Juju status: in tabular format: http://paste.ubuntu.com/19501334/

  Juju status in yaml format: http://paste.ubuntu.com/19501233/

  Here machine 0 is the bootstrap node, where the dns name is an IP from the managed(DNS and DHCP) network that is from 10.9.1.x series.
  But in case of other nodes(1, 2 and 3) the dns name are the IP from the unmanaged network that is from 10.10.11.x series

  With Juju 2.0 beta5:
  MAAS (Running in a VM in Virtual machine manager)
                  Version 1.9
                  eth0: 192.168.7.101(Unmanaged)
                  eth1: 10.14.0.1(MANAGED)
  JUJU (in a VM in Virtual machine manager)
                  Version 2.0 beta5
                  eth0: 192.168.7.103
                  eth1: 10.14.0.151
                  DNS: 10.14.0.1

  Content of .local/share/juju/controller.yaml
  controllers:
    local.cplane-controller:
      unresolved-api-endpoints: ['192.168.7.113:17070', '10.14.0.100:17070']
      uuid: eab2b453-e719-40e4-8453-76441986207b
      api-endpoints: ['192.168.7.113:17070', '10.14.0.100:17070']

  Juju status:
   [Machines]
  ID STATE DNS INS-ID SERIES AZ
  0 started 10.14.0.100 /MAAS/api/1.0/nodes/node-22777ed6-0de4-11e6-8c34-000c297e53d6/ trusty default
  1 pending 10.14.0.102 /MAAS/api/1.0/nodes/node-248caeb2-0de4-11e6-94c7-000c297e53d6/ trusty default
  2 pending 10.14.0.103 /MAAS/api/1.0/nodes/node-2523d274-0de4-11e6-8747-000c297e53d6/ trusty default
  3 pending 10.14.0.101 /MAAS/api/1.0/nodes/node-22fd8fda-0de4-11e6-b551-000c297e53d6/ trusty default

  Additional info:
  We tried to use --bind to deploy the charm to a specific network space, but it doesn't work.
  We defined 2 spaces in MAAS:
  unused: 10.10.11.x series
  default: 10.9.1.x series

  These spaces can be listed through the juju command "juju list-spaces"
  in the juju controller node, which is listing all the spaces in our
  setup properly. We 'juju deploy juju-gui --bind Default<please
  confirm>' but the preferred private-address is still from the
  10.10.11.x series. Used juju run --unit juju-gui/0 "unit-get private-
  address" to check.

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1603473/+subscriptions