echeadle (87) [Avatar] Offline
#1
I am very close to having devstack up and running, but I am getting network errors.

In the local.conf file you had addresses below listed. I get errors like:

ROUTER_GW_IP=192.168.1.2
2014-05-08 17:52:30.097 | + die_if_not_set 427 ROUTER_GW_IP 'Failure retrieving ROUTER_GW_IP'
2014-05-08 17:52:30.101 | + local exitcode=0
2014-05-08 17:52:30.106 | + sudo route add -net 10.0.0.0/24 gw 192.168.1.2

In the local.conf file:
HOST_IP=10.163.200.32 <<-- I used my server's actual ip address
FLOATING_RANGE=192.168.1.0/24
PUBLIC_NETWORK_GATEWAY=192.168.1.1
FIXED_RANGE=10.0.0.0/24

I think it is my confusion about what each of these are. In the book you talk about the GENERAL_NETWORK. Is that the FIXED_RANGE or the FLOATING_RANGE network? I assume the HOST_IP is the address of the server on which I installed devstack.

What is the PUBLIC_NETWORK_GATEWAY? Is it the same gateway I use in the ifcfg-eth0 of my server? Is it the server's ip address? Is the public network the network I have my server connected to? I am looking at error messages and drawings and explanations and I think I have my self confused between the various networking layers. My next step is to un-confuse myself concerning the network. I was spending a lot of time getting the scripts running and did not have time to dive in.

I think I worked out all the issues with proxies, but I wonder if this network problem is related to the solution I came up with to solve the proxy issues.
cody.bumgardner (57) [Avatar] Offline
#2
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
Hi Echeadle,

OpenStack networking can be very frustrating. There are so many layers it is very easy to get sideways.

Basically, the networks defined in local.conf *should* be built by Devstack. With the exception of the HOST_IP, as you identified, no other address or adapter needs to be configured on the system, before running stack.sh. The instructions were written so that a person with a single adapter could still complete the exercises.

That being said, things change all the time in OpenStack/DevStack, and configs that work today might not work tomorrow.

HOST_IP=[actual address of your adapter (eth0, etc.)
FLOATING_RANGE=[range of floating addresses.. externally accessible from OpenStack] *Does not need to exist before stacking
PUBLIC_NETWORK_GATEWAY=[gateway address of public network that will be used to connect internal OpenStack networks with external networks.]
FIXED_RANGE=[internal network range for VMs to use]

Basically, in ch2 to deploy DevStack, which should contain networks specified in the local.conf. Then in ch3, you build a new Tenant (internal) network named GENERAL_NETWORK. You are recreating an internal network like the one that should have already been created by the DevStack process.


Once reviews are complete I will go back through this process and refine it. I also expect I will need to develop a test suite to make sure configs still work with the latest stable versions of DevStack.

Thanks,
Cody
echeadle (87) [Avatar] Offline
#3
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
Your explanations make perfect sense. It is what I originally thought at first. I started doubting myself when it did not work so I was questioning my understanding.

ip nms is something to do with namespaces. Without the command, it is my understanding, that the network does not get set up properly. The errors I was looking at happened way before the ip nms error so I incorrectly thought it had to do with the way I was setting it up.

Things are working now, I've slowed down a bit because I am attending a conference, but hopefully I will get back to reading the new material and working on devstack soon.

Thanks for the explanation.
echeadle (87) [Avatar] Offline
#4
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
[root@lslcopenstack01 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.24.4.0 * 255.255.255.0 U 0 0 0 br-ex
10.0.0.0 172.24.4.2 255.255.255.0 UG 0 0 0 br-ex
10.22.40.0 * 255.255.255.0 U 0 0 0 eth0
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
default gateway1 0.0.0.0 UG 0 0 0 eth0

Here is the output of the route command when I put only the host ip address in the local.conf file.

If you have some time, could you post the output of the route command and the ifcfg-eth0 <assuming this is what is connected to the public network>

The network my host is attached to is the 10.22.40.0 subnet.

If I could see information from a working system, I might figure out why I am so confused and what I might need to change.
cody.bumgardner (57) [Avatar] Offline
#5
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
Echeadle,

Sorry for the trouble, but we will get there.

--Warning--
The following network information is based on what should exist through ch2. The demo tenant is sufficient to make sure networking is properly configured. The tenant/network configuration in ch3 is simply replicating what was created in the demo tenant.
--Warning--


I have attached the output of the route command in the file route.txt.

Can you post the output of your interface config (ifconfig -a)?

My physical server is connected to the network via eth0.
eth0 inet addr:10.163.200.32 Bcast:10.163.200.255 Mask:255.255.255.0

My VM is on 10.0.0.11 and uses the gateway 10.0.0.1.

I have also posted by interface config: ifconfig.txt, the iptables config: iptables.txt before the NAT translation command (sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE) and the iptables: iptables_post.txt after the command.

I will go through ch3 and see how the config changes.

Thanks,
Cody
cody.bumgardner (57) [Avatar] Offline
#6
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
I just went through ch3 and I can confirm that my routes are the same.

The tenant (internal) networks added in ch3 should not show up under the Linux routing tables or interfaces.

On the GENERAL_NETWORK in my GENERAL tenant I have a VM with the IP= 172.24.220.2 that can communicate to the rest of the work. However, this address range does not show up on the OS level.

I am not sure why yours does. I would do a clean then reboot. Take another look at the local.conf making sure that the HOST_IP matches your eth0 ip. Then try it again.

At the end of ch2 you should be able to access external networks (internet) from VMs. Make sure you ping an ip and not a host name, since I don't think DNS is set automatically.

Cody
echeadle (87) [Avatar] Offline
#7
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
Cody,
Thanks for all your help. You postings detailing your network settings helped and now: Success!

I was still having issues. When running stack.sh it would be doing something with keystone and the following error occurred: AttributeError: ‘module’ object has no attribute

I found: http://blog.willmer.org/2007/12/attributeerror-module-object-has-no-attribute-blah/

This may help, but in working with the system trying some of the fixes the web page suggested; It croaked.

I started over. Following the steps I posted in RHEL 6.5 Installation. I made a couple of changes, I commented out all the network settings except HOST_IP.
I put STACK_USER=stack in stackrc. It did not seem to work in local.conf.

And from RHEL 6.5 Installation:
#Changed 5/23/2014 I removed the following three lines
#FLOATING_RANGE=192.168.1.0/24
#PUBLIC_NETWORK_GATEWAY=192.168.1.1
#FIXED_RANGE=10.0.0.0/24

After running stack.sh I ran:
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Now I have an internal network of 10.0.0.0/24 that can ping the outside world.

I have a running Devstack so now on the the next challenges.
cody.bumgardner (57) [Avatar] Offline
#8
Re: Is the FIXED_RANGE var in local.conf the same as the General Network
Wonderful news!

If I can stick with a single line for the network config I certainly will.

Good luck with the rest of the chapters.

The second part of the book should arrive much quicker than the first part since I have been working on it for a while already.

Thanks for all of your helpful comments and information.

Cody