Comment 5 for bug 1786666

It is working as expected. For more information, please see the below mail.

From: Michael Henkel <email address hidden>
Date: Thursday, October 18, 2018 at 12:22 AM
To: Yuvaraja Mariappan <email address hidden>, Jeba Paulaiyan <email address hidden>
Cc: Sachchidanand Vaidya <email address hidden>, Alok Kumar <email address hidden>
Subject: Re: generic linklocal service failing

Hi Yuvaraja,

Thanks, that makes sense.
The Fabric Address can only be a destination which is routed/reachable through the vhost0 interface and not any other interface on the compute node.
I verified it by setting the route to the external_api (public) network through vhost0 and with that I can reach the api server:

{
· linklocal_service_name: bla
· ip_fabric_service_ip: [
o 10.2.0.15
]
· linklocal_service_ip: 169.254.169.111
· ip_fabric_service_port: 8082
· ip_fabric_DNS_service_name:
· linklocal_service_port: 8082
· lls_fab_address_ip: IP
}

10.2.0.0/24 is the external/public network.,

Route on the compute node:

[root@overcloud-novacompute-0 heat-admin]# ip route get 10.2.0.15
10.2.0.15 via 10.0.0.1 dev vhost0 src 10.0.0.11

(10.0.0.1 is a GW which has to have a route to 10.2.0.15)

On the VM:
$ curl 169.254.169.111:8082|more
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"href": "http://169.254.169.111:8082", "links": [{"link": {"href": "http://169.254.169.111:8082/documentation/index.html", "name": "documentation", "rel": "documentation", "method": "GET"}}, {"link": {"href": "http://169.254.169.111:8082/config-root", "name": "config-root", "rel": "root", "method": null}}, {"link": {"href": "http://169.254.169.111:8082/global-analytics-configs", "name": "global-analytics-config", "rel": "collection", "method": null}}, {"link": {"href": "http://169.254.169.111:8082/physical-interfaces", "name": "physical-interface", "rel": "collection", "method": null}},….

We need to document that internal_api IPs cannot be used as Fabric Address destinations IF tenant and internal api are on different interfaces on the compute node.

The good thing is that I learnt that metadata is not ‘just’ a name for the service.
A feature request for the future would be to set a Link Local Service to either NAT or proxy. In proxy we can then even use internal_api addresses.

@Jeba the bug can be closed as it is not a bug.

Regards,
Michael

From: Yuvaraja Mariappan <email address hidden>
Date: Thursday, October 18, 2018 at 6:04 AM
To: Michael Henkel <email address hidden>
Cc: Sachchidanand Vaidya <email address hidden>, Alok Kumar <email address hidden>, Jeba Paulaiyan <email address hidden>
Subject: Re: generic linklocal service failing

Hi Michael,

                It seems, it is a known behavior.
                Agent works as a web proxy if the link local service name is metadata and linux routing is used to forward the packet to the link-local endpoint.
For other names, agent setups flow with natting and vrouter does the packet forwarding.
Since there is a reachability to 10.1.0.18 from linux routing, metadata link-local service always works where as there is no reachability from vrouter interface to 10.1.0.18 which causes the failure for other link-local services.
We have to use control data ip of the controller as an endpoint rather than the mgmt ip in the link-local service.
Also I have tried a patch to use web proxy path, if link local service name starts with ‘metadata’ [i.e name can be ‘metadata’ , ‘metadata1’, ‘metadata2’ … and not ‘11metadata’, …]
[If there is a real requirement to have more than one metadata services, then we can think about it]

Thanks,
Yuvaraja