Training labs parser will allow us to automatically parse RST code to BASH. This BASH code in turn will be invoked by install-guides for validating the install guides. To provide the correct information to the parser for generating BASH code, there are a few changes required to the RST syntax. Introduces the following changes to RST syntax: - `.. end` This tag provides information for the parser to stop extracting the given block which could be code, file injection or configuration file edit. - `.. endonly` This tag provides information for the parser with the correct distro-switch logic for identifying distro-specific code. For .. only:: tags, it is better to avoid nesting. If nesting is not avoidable then it is preferable to add the .. endonly tag to close the outer block immediately. - Extra new lines in code-blocks Some commands in the code-blocks provides the expected output of the given command. This is not a BASH command which we want to run but rather some visual niceness for the users. These new lines provides the parser information to identify the end of the command. This basic logic would be something similar to find '\r\n' which at least for python means new empty line. - `mysql>` Introducing this operator for mysql commands. This could potentially be changed to `pgsql>` or similar for other SQL type databases. This allows the parser to identify mysql commands and then run them in mysql instead of in 'sh' or 'bash'. - `.. path` Introducing this tag to provide the parser with the information with the path of the configuration file. Using the description text for the same is not reliable since the description text may not be consistent. This commit should ideally introduce all the syntax changes required for the parser to convert the code-blocks in here to BASH code. These changes should have no impact on the HTML output of the RST code. Change-Id: I47830b1bc61c8b1a0f3350932d15aa3ce88fa672
3.4 KiB
Verify connectivity
We recommend that you verify network connectivity to the Internet and among the nodes before proceeding further.
From the controller node, test access to the Internet:
# ping -c 4 openstack.org PING openstack.org (174.143.194.225) 56(84) bytes of data. 64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms 64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms 64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms 64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms --- openstack.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3022ms rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
From the controller node, test access to the management interface on the compute node:
# ping -c 4 compute1 PING compute1 (10.0.0.31) 56(84) bytes of data. 64 bytes from compute1 (10.0.0.31): icmp_seq=1 ttl=64 time=0.263 ms 64 bytes from compute1 (10.0.0.31): icmp_seq=2 ttl=64 time=0.202 ms 64 bytes from compute1 (10.0.0.31): icmp_seq=3 ttl=64 time=0.203 ms 64 bytes from compute1 (10.0.0.31): icmp_seq=4 ttl=64 time=0.202 ms --- compute1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
From the compute node, test access to the Internet:
# ping -c 4 openstack.org PING openstack.org (174.143.194.225) 56(84) bytes of data. 64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms 64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms 64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms 64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms --- openstack.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3022ms rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
From the compute node, test access to the management interface on the controller node:
# ping -c 4 controller PING controller (10.0.0.11) 56(84) bytes of data. 64 bytes from controller (10.0.0.11): icmp_seq=1 ttl=64 time=0.263 ms 64 bytes from controller (10.0.0.11): icmp_seq=2 ttl=64 time=0.202 ms 64 bytes from controller (10.0.0.11): icmp_seq=3 ttl=64 time=0.203 ms 64 bytes from controller (10.0.0.11): icmp_seq=4 ttl=64 time=0.202 ms --- controller ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
Note
rdo or obs
Your distribution enables a restrictive firewall
by default. During
the installation process, certain steps will fail unless you alter or
disable the firewall. For more information about securing your
environment, refer to the OpenStack Security Guide.
ubuntu or debian
Your distribution does not enable a restrictive firewall
by default. For
more information about securing your environment, refer to the OpenStack Security Guide.