Container on sshprovided machine doesn't respect net binding

Bug #1819171 reported by Peter Sabaini on 2019-03-08
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
High
Unassigned

Bug Description

I've added a physical node via juju add-machine ssh:... which has one interfaces on oam-net (ipv4) and ext-net (ipv6). Deploying a containerized application with interfaces in both networks gets me a container with both an ipv4 and ipv6 address as expected.

However, even though the charm is deployed with --bind oam-space the unit uses the ipv6 addr from ext-net as it's primary address, and relations to the unit therefore fail.

Juju 2.5.1 on xenial

Richard Harding (rharding) wrote :

Can you also provide the output of juju spaces as we as juju show-machine X where it's the machine you added to the model manually?

I want to see how the spaces are defined such that binding to them should have worked but did not.

Thanks

Changed in juju:
status: New → Incomplete
Peter Sabaini (peter-sabaini) wrote :

Pasting a redacted version below

Manual provisioning
$ juju add-machine --constraints "tags=infra,spaces=space-oam,space-ext" ssh:ubuntu@10.0.0.4

$ juju spaces
Space Subnets
space-ext 10.0.0.0/24
space-oam 10.1.0.0/24

$ juju show-machine 0
model: openstack
machines:
  "0":
    juju-status:
      current: started
      since: 08 Mar 2019 11:58:28+01:00
      version: 2.5.1
    dns-name: 10.0.0.4
    ip-addresses:
    - 10.0.0.4
    - 10.1.0.130
    instance-id: manual:10.0.0.4
    machine-status:
      current: running
      message: Manually provisioned machine
      since: 08 Mar 2019 11:58:18+01:00
    series: xenial
    network-interfaces:
      br-ext:
        ip-addresses:
        - 10.1.0.130
        mac-address: xx:xx:xx
        gateway: 10.1.0.129
        space: space-ext
        is-up: true
      br-oam:
        ip-addresses:
        - 10.0.0.4
        mac-address: xx:xx:xx
        space: space-oam
        is-up: true
      lxdbr0:
        ip-addresses:
        - 10.0.88.1
        mac-address: yy:yy:yy
        is-up: true
    hardware: arch=amd64 ...

Test container:

$ juju deploy ubuntu --to lxd:0 --constraints spaces=space-oam,space-ext --bind space-oam --series=xenial

Changed in juju:
status: Incomplete → New
Peter Sabaini (peter-sabaini) wrote :

PS.: for clarification, the ext-net on machine #0 has both ipv4 and ipv6; the interface of the metal actually only has an ipv4 addr bound

My first guess would be that we don't notice that manually provisioned
machines are in valid spaces. Because they are manually provisioned, there
is no Provisioner information about what that subnet actually means. Likely
we could try a best-effort matching "if it looks like 192.168./16 then just
assume it is the same one as the others claim to be".

I could be wrong about it.

John
=:->

On Fri, Mar 8, 2019 at 8:25 PM Peter Sabaini <email address hidden>
wrote:

> PS.: for clarification, the ext-net on machine #0 has both ipv4 and
> ipv6; the interface of the metal actually only has an ipv4 addr bound
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1819171
>
> Title:
> Container on sshprovided machine doesn't respect net binding
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1819171/+subscriptions
>

Changed in juju:
status: New → Triaged
importance: Undecided → High
milestone: none → 2.6-beta1
Changed in juju:
milestone: 2.6-beta1 → 2.6-beta2
Changed in juju:
milestone: 2.6-beta2 → 2.6-rc1
Changed in juju:
milestone: 2.6-rc1 → 2.6-rc2
Changed in juju:
milestone: 2.6-rc2 → 2.6.1
Changed in juju:
milestone: 2.6.1 → 2.6.2
Changed in juju:
milestone: 2.6.2 → 2.6.3
Changed in juju:
milestone: 2.6.3 → 2.6.4
Changed in juju:
milestone: 2.6.4 → 2.6.5
Changed in juju:
milestone: 2.6.5 → 2.6.6
Changed in juju:
milestone: 2.6.6 → 2.6.7
Changed in juju:
milestone: 2.6.7 → 2.7-beta1
Changed in juju:
milestone: 2.7-beta1 → 2.7-rc1
Changed in juju:
milestone: 2.7-rc1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers