juju fan network container do not have access from outside model

[Narinder Gupta]

Hello All.
We are deploying a single LMA stack for baremetal openstack with MAAS and kubernetes model on openstack provider using cross model relationship. Everything is ok and we managed to connect openstack VMs with LMA stack with nagios. But all lxd container on VMs uses fan networking and we are nagios is unable to connect to contact the etcd and easyrsa service which is running in LXD container.

There should be a way to assign floating ips or use host public address to those containers if needed so that Nagios can contact container and get the data required.

Thanks and Regards,
Narinder Gupta

[Richard Harding (rharding)]

If the containers need addresses on a specific space to be contactable from other services during deployment the spaces requirements need to be specified using the bind configuration. Is there a sample of this behavior/bundle that defines the applicable network requirements for the topology you describe here?

Marking incomplete as we gather details about the setup and expectations.

[John A Meinel (jameinel)]

I'd probably start by saying that fan networking is pretty much designed to
not be accessible outside of the local subnet. So if you want remotely
accessible services, then fan networking is not how you should be setting
up the applications. Part of the security benefit is that you know they
aren't accessible.
It would be possible to do something like put a load balancer in front
(HAProxy running on the host machine).
It is unclear to me why fan networking is a better solution for your case
than using the host's IP space in the first place. MAAS has no problems
handing out IP addresses to the containers we provision. It seems a bit of
a contradiction to put things into an unroutable space and then ask for
routes to it.

On Mon, Apr 8, 2019 at 4:35 PM Richard Harding <email address hidden>
wrote:

> If the containers need addresses on a specific space to be contactable
> from other services during deployment the spaces requirements need to be
> specified using the bind configuration. Is there a sample of this
> behavior/bundle that defines the applicable network requirements for the
> topology you describe here?
>
> Marking incomplete as we gather details about the setup and
> expectations.
>
> ** Changed in: juju
> Status: New => Incomplete
>
> --
> You received this bug notification because you are a member of Canonical
> Field Medium, which is subscribed to the bug report.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1823337
>
> Title:
> juju fan network container do not have access from outside model
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1823337/+subscriptions
>

[Narinder Gupta (narindergupta)]

On clouds by default juju use fan networking which causes all containers on fan network which breaks the log consolidation through Nagios. As Nagios uses public ip of container to access the units and it fails to contact as it is in different model.

Only option we left is using the VMs than containers so thay two juju models application can talk to each other. I think there should be a way to assign the public ips/floating ips to those containers in case need arises.

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[Bartosz Woronicz (mastier1)]

Confirm, I would love to see such option.