0
votes

Good day,

Today I am seeking to be redirect all incoming and outgoing traffic from the private IP of my BareMetal Instance to the IP initially given to DevStack during installation.

OpenStack BareMetal Cloud Setup

How I came to this situation? I am working with an OpenStack environment where I am capable of deploying a BareMetal Instance (Floating IP:XXX.YYY.88.171, Private IP: 10.140.82.189 [On eth0]). The image utilized to spin this instance is Ubuntu 14.04 with DevStack /Master installed. The snapshot for this image with DevStack installed on it was created initially on a BareMetal with local IP: 10.140.82.125 [On eth0]. Therefore, now whenever you use this spin-up an instance with this image, the Baremetal OpenStack environment assigns a private IP (in this case 10.140.82.189) different to the IP contained on all DevStack's endpoints (10.140.82.125).

This as you can imagine gives us a lot of problems.

The two best approaches to solve this problem that I can think of are:

  1. Changing all DevStack endpoints from 10.140.82.125 to 10.140.82.189 (There are a lot of issues to consider on each update when following this route)

  2. Forwarding all traffic from 10.140.82.189 to 10.140.82.125 for each endpoint.

My progress:

First I wasn't even able to access the horizon dashboard (even-though it was displayed when typing in the browser) which in essence will follow:

XXX.YYY.88.171 --> 10.140.82.189:8800 --> 10.140.82.125:8800

For some reason this displays the Instance's Horizon dashboard. When I typed my user name and password I will returned with

Unable to establish connection to keystone endpoint.

In the terminal where I ssh to 10.140.82.189 if I request:

openstack catalog list
Unable to establish connection to http://10.140.82.125:5000/v2.0/tokens

So it seems that 10.140.82.189 is carrying in its API call its IP and requesting keystone for a token on 10.140.82.125:5000. Due to the IP mismatch there is a problem and it doesn't allow me to login.

I proceeded to perform a small port forwarding by doing the following:

 sudo ip addr add 10.140.82.125/22 dev eth0

 sudo iptables -t nat -A  PREROUTING -d 10.140.82.189 -j DNAT --to-destination 10.140.82.125

 sudo iptables -t nat -A POSTROUTING -s 10.140.82.125 -j SNAT --to-source 10.140.82.189

Now I am able to log in to mi account and obtain the endpoints in the terminal. Unfortunately, inside horizon no information is retrieved from nova (http://10.140.82.125:8774) or any of the other services. Trying to spin-up an instance in the DevStack environment gives me the following:

Error: Failed to get network list Connection to neutron failed: HTTPConnectionPool(host='10.140.82.125', port=9696): Max retries exceeded with url: //v2.0/networks.json?shared=False&tenant_id=bec332d4b9e6415cae0f51bb3e0de720 (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7fd168377b90>: Failed to establish a new connection: [Errno 111] Connection refused',))

List of endpoints: Shown in Comments

I keep getting errors all over the place. As an example (using screen on devstack):

On glance-registry:

 2016-01-20 06:09:23.173 DEBUG eventlet.wsgi.server [-] (8212) accepted ('10.140.82.189', 38273) from (pid=8212) server /usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py:826

Neutron-svc (q-svc)

 2016-01-20 06:17:30.581 WARNING neutron.db.agents_db [req-48ebcdf0-126c-4dfb-b3b2-f4b48ec9704a None None] Agent healthcheck: found 4 dead agents out of 4:
            Type       Last heartbeat host
      DHCP agent  2016-01-13 19:08:16 gonzalo-devstack-ss
        L3 agent  2016-01-13 19:08:08 gonzalo-devstack-ss
  Metadata agent  2016-01-13 19:07:51 gonzalo-devstack-ss
 Open vSwitch agent  2016-01-13 19:08:16 gonzalo-devstack-ss
 2016-01-20 06:17:32.319 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server 10.140.82.125:5672 closed the connection. Check login credentials: Socket closed

q-agt:

 2016-01-20 06:19:14.308 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server 10.140.82.125:5672 closed the connection. Check login credentials: Socket closed

And I could keep going. What would be the recommendation on moving forward?

1
DevStack Endpoints [link] (paste.openstack.org/show/484373)Gonzalo De La Torre

1 Answers

0
votes

The proposed approach is not possible unless you create an additional API "traducer" which replaces the old IP with the new IP and the old host name with the new host name.

The solution to this problem is to completely replace the previous IP with the new IP and the previous host name with the new host name. This must be done in /etc and /opt/stack in addition to the information contained in all tables in mysql databases.