Getting through this may come up with several issues and requires some workarounds. The default method of deployment is "bare metal" meaning you are going to provision out other servers. You need to use "-virtual" as a parameter to deploy.sh in order to provision VMs rather than 5 other bare metal servers. Please follow these steps:

1.  Install CentOS 7 on a server that has minimum
  * 250GB storage
  * 18 GB RAM (10 GB for non-HA)
  * 1 NIC configured with internet access
2.  git clone https://gerrit.opnfv.org/gerrit/genesis
3.  cd genesis/foreman/ci
4.  Depending where you are:
  * If in China: ./deploy.sh -virtual -ping_site www.baidu.com -static_ip_range <your_range>
  * Otherwise:   ./deploy.sh -virtual -static_ip_range <your_range>
  * For non-HA: ./deploy.sh -virtual -static_ip_range <your_range> -base_config <full path to pwd>/opnfv_ksgen_settings_no_HA.yml

Where <your_range> is a continous block of public IP addresses you can use, e.g.: 192.168.1.101,192.168.1.120

The IP range can be determined by just looking at the "ifconfig" output and starting at the next "x01" in the 192.168 range. For example, in an environment on Wi-Fi at home, this range ended up being 192.168.1.201,192.168.1.220.

A successful deployment should complete with the following line:

Virtual deployment SUCCESS!! Foreman URL:  http://192.168.1.201, Horizon URL: http://155.1.2.3

It is noticed that if you pick an IP range whose subnet is not in the same subnet as the default gateway, the created VMs inexplicably cannot access the internet. It would be a good thing to verify at the beginning of the script and report an error if this is discovered.

If you see the following in the console:

==> default: Specific bridge 'eth_replace0' not found. You may be asked to specify
==> default: which network to bridge to.
==> default: Available bridged network interfaces:
    1) wlo1
    2) enp0s25
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
    default: Which interface should the network bridge to?

The fact that you hit this prompt at all was a bug. It normally can automatically find the correct interface (it should have found "wl01"), but the script skips any interfaces with "lo" in the name, attempting to skip "loopback" interfaces. The workaround is to change the regexp to look for "^lo" instead of "lo".

The entire change was changing line 945 from this:

    output=`ifconfig | grep -E "^[a-zA-Z0-9]+:"| grep -Ev "lo|tun|virbr|vboxnet" | awk '{print $1}' | sed 's/://'`

to:

    output=`ifconfig | grep -E "^[a-zA-Z0-9]+:" | grep -Ev "^lo|^tun|^virbr|^vboxnet" | awk '{print $1}' | sed 's/://'`

This bug was filed as https://jira.opnfv.org/browse/APEX-11. One concern is that assuming semantics of an interface based on its name is suspect at best.

Please note that APEX-11 has been fixed since September 4, 2015 for both VM and bare metal deployment.

At this point, since the deployment is half done, you may have to do some cleanup before restarting. You can run the "clean.sh" script. Or if it doesn't work, you may have to go to "/var/opt/opnfv" and go to each of the VMs defined in that folder (an older version of this script created the VMs in /tmp, which made rebooting the box awkward) and do "vagrant destroy" and then verify no VMs were running afterwards, with "vboxmanage list runningvms", and then delete the entire "opnfv" directory.

The first attempt to reach the Foreman URL from Firefox will likely fail, unless Firefox wasn't running when you ran the deployment. If it was running, just exit it and restart. If this is isn't your first complete run through the deployment, this might still fail because of an invalid certificate, which is installed as part of the deployment. Fix this by going into your Firefox preferences and deleting the cert with "opnfv" in the URL.

Another issue that you may run into is that the internet is initially unreachable from any of these VMs. This is because they somehow get two default routes, one of which is invalid. This is evident if you see something like this:

[root@oscontroller1 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 enp0s10
default         10.0.2.2        0.0.0.0         UG    0      0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s3

The fix is to remove the "10.0.2.2" gateway with:

route del default gw 10.0.2.2

This is logged at https://jira.opnfv.org/browse/APEX-2, which should have been fixed.