First of all, some context.
I'm using Juju 2.3.5 on GCE and discovered this behavior while deploying the Kibana and ElasticSearch charms of omnivector. Although, I don't think the charms matter. Both charms are deployed on separate Google VMs, so no containers involved. And to be 100% clear, I haven't tried it with an AWS controller.
I noticed from the Kibana UI, it couldn't actually reach the ElasticSearch unit. While debugging the process, I noticed Fan was deployed on both VMs, although I'm not using any LXD containers. And both charms used the Fan IP address as their private IP addresses. That's why during the relation conversation the ElasticSearch charm passed a wrong IP address to Kibana.
Some commands I tried during my quest.
- on my Juju client:
```
juju run --unit elasticsearch/0 'network-get public --ingress-address --format yaml'
252.1.240.1
```
- in debug-hooks on my Kibana unit, and in python3 shell:
```
>>> unit_get('private-address')
'252.1.224.1'
>>> network_get('public')
{'ingress-addresses': ['252.1.224.1'], 'bind-addresses': [{'macaddress': '62:b6:9e:a6:c7:8a', 'interfacename': 'fan-252', 'addresses': [{'cidr': '252.0.0.0/8', 'address': '252.1.224.1'}]}]}
```
When you need more information, always happy to provide it.
Thanks,
Gregory
I don't believe in GCE we automatically configure a Fan config. However,
due to the way the fan works, if you would run containers then you need to
be advertising the fan addresses even for processes that are not in
containers. (it is how the fan determines whether it can use direct
addressing or needs to NAT packets.)
How is your networking configured such that the host machines can reach
each other but not reach each other on FAN addresses? (are they on
different networks/
I'm pretty sure this means you configured fan-config. Are you planning on
using it, just playing with it to experiment, using containers but just not
for these applications, ?
John
=:->
On Fri, Apr 6, 2018, 22:50 Gregory Van Seghbroeck <
<email address hidden>> wrote:
> Public bug reported:
>
> First of all, some context.
> I'm using Juju 2.3.5 on GCE and discovered this behavior while deploying
> the Kibana and ElasticSearch charms of omnivector. Although, I don't think
> the charms matter. Both charms are deployed on separate Google VMs, so no
> containers involved. And to be 100% clear, I haven't tried it with an AWS
> controller.
>
> I noticed from the Kibana UI, it couldn't actually reach the
> ElasticSearch unit. While debugging the process, I noticed Fan was
> deployed on both VMs, although I'm not using any LXD containers. And
> both charms used the Fan IP address as their private IP addresses.
> That's why during the relation conversation the ElasticSearch charm
> passed a wrong IP address to Kibana.
>
> Some commands I tried during my quest.
>
> - on my Juju client:
> ```
> juju run --unit elasticsearch/0 'network-get public --ingress-address
> --format yaml'
> 252.1.240.1
> ```
> - in debug-hooks on my Kibana unit, and in python3 shell:
> ```
> >>> unit_get(
> '252.1.224.1'
> >>> network_
> {'ingress-
> '62:b6:
> 252.0.0.0/8', 'address': '252.1.224.1'}]}]}
> ```
>
> When you need more information, always happy to provide it.
>
> Thanks,
> Gregory
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https:/
>
> Title:
> On GCE (Juju 2.3.5) when requesting the private IP address of a unit,
> I always get the FAN IP address.
>
> To manage notifications about this bug go to:
> https:/
>