The yum command has been replaced by the dnf command in recent releases
of Fedora-based distributions. Use the native command instead of
the alias kept for compatibility.
Change-Id: I0a1dfdaca91164eff2c25795f66976ec70356574
smooney noted that using your DevStack host as a jump host is yet
another reasonable option. Add this option also.
Change-Id: I24887c254e131a8979653a7d17e64a708acf294a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Detail how one can SSH into guests running on a remote DevStack host.
Change-Id: I9f988b1193d67859b129f05d08b32a23e50aee49
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This is really easy win for people using DevStack for the first time.
Change-Id: I8de2d4d115d34e9d87dd461016b5b894d3f000e7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The FLOATING_RANGE variable should specify the network address of the
used prefix for clarity.
Change-Id: I547bd42d8bdc5f0f2001d47f2d5b43729773b1bc
Closes-Bug: 1870204
In the 'Private Network Addressing' section of the doc,
there are references to FIXED_RANGE when referring to V6
networks. These have been changed to FIXED_RANGE_V6.
Also fixed a few typos and grammatical errors when
giving the doc a quick read-through looking for more
references to FIXED_RANGE.
Change-Id: Iaa530c476ce2b36a3f616945ddd2e24fa599a16c
The switch to using subnetpools caused quite a bit of confusion
because it didn't respect the value of FIXED_RANGE. This caused
conflicts in the gate with it's default IPv4 value of 10.0.0.0/8.
This patch does a few things to address the issue:
* It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE
values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values
to dervive from them by default.
* This addresses the concern that was raised about implying that
SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting
SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value
for the operator specify a chunk of addresses that are safe to
use for private networks without implementation implications.
* Backwards compatibility is maintained by alloing users to override
override all of these values.
* The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24
* Because we want to be able to use subnetpools for auto allocated
topologies and we want to be able to have a large chunk of
instances on each network, we needed a little more breathing room
in the default v4 network size.
* SUBNET_POOL_SIZE_V4 default is changed from 24 to 26
* In conjuction with this change and the one above, the default
subnetpool will support up to 16 64-address allocations.
* This should be enough to cover any regular gate scenarios.
* If someone wants a bigger/smaller subnet, they can ask for that
in the API request, change this value themselves, or use a different
network entirely.
* FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE
* This avoids the private subnet in the non-subnetpool case from being
larger than /64 to avoid issues identified in rfc 7421.
* Users can still explicitly set this value to whatever they want.
This 'max' behavior is only for the default.
* This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves
tons of room for v6 subnetpools.
Closes-Bug: #1629133
Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
This explains the current state of networking in devstack, and a
couple of scenarios that people might want to try out for local
testing.
Change-Id: I2be35f4345bf9306c981ef6f0186b48da7d06772
