Rubygem-Staypuft: Deployment of HA Neutron with vxlan on bare metal gets stuck on 60% installing the controllers.
Steps to reproduce:
1. Install rhel-osp-installer.
2. Configure/run an HA deployment of neutron network with Vxlan tenant network type, em1 for Network Nodes and em2 for compute nodes.
The deployment gets paused with errors on 60% installing the controllers. I saw no puppet errors in UI. Resumed the deployment after several hours (in the morning). The deployment continued and got paused with errors on 60% installing the compute node. The puppet error I see on the compute node is:
Could not retrieve catalog from remote server: Error 400 on SERVER: Local ip for ovs agent must be set when tunneling is enabled at /etc/puppet/environments/production/modules/neutron/manifests/agents/ovs.pp:32 on node <nodename>
Deployment successfully completed 100%.
Created attachment 920991 [details]
/var/log/messages file from the staypuft machine.
Created attachment 920992 [details]
production.log from the staypuft host.
Created attachment 920995 [details]
/var/log/messages file from the compute node.
It looks the same ERROR in : https://bugzilla.redhat.com/show_bug.cgi?id=1122302
"ip for ovs agent must be set when tunneling is enabled at /etc/puppet/environments/production/modules/neutron/manifests/agents/ovs.pp:32 on "
*** Bug 1122302 has been marked as a duplicate of this bug. ***
*** Bug 1125217 has been marked as a duplicate of this bug. ***
Current workaround is to do either:
* enable dhcp on the subnet that is not getting an ip address
* configure the nic with a static ip in the kickstart
Real solution is network provisioning which is coming in a future version.
(In reply to Mike Burns from comment #9)
> Current workaround is to do either:
> * enable dhcp on the subnet that is not getting an ip address
Who is the DHCP server in this case ?
> * configure the nic with a static ip in the kickstart
Can you please add information how to do it ?
> Real solution is network provisioning which is coming in a future version.
I am not sure this helps but I have this problem on deployment where I did NOT check to "configure external network on the networking node" or something like that.
all of my nics on the networking node have IPv4
This is caused by that the discovery OS does use probably only eth* ifaces names, but the real os, that is installed after clicking on the deploy, is using weird names (ens*) for the realtec ifaces. So set all the interfaces to virtio before starting the VMs and you're good.
These "weird" names will pop up on RHEL7 - particularly on bare metal (unless using the workaround with kernel argument).
Anyway, you have to identify each interface - and know which network it is connected to. Even if it's called ethX.
There are 2 issues mentioned in this bug:
1. nic naming is different between discovery and RHEL 7 -- this is documented now and will be solved by bug 1122726
2. interfaces without IPs -- this will be handled with future network provisioning (multiple bugs opened on this)
Closing this as a duplicate
*** This bug has been marked as a duplicate of bug 1122726 ***