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
The neutron client is going to be deprecated during the
Ocata timeframe, so it is time to start switching to the
openstack client to invoke networking commands.
use of neutron client in neutron-legacy has been left as is.
The command for setting the router gateway is left as follow up.
Change-Id: I0a63e03d7d4a08ad6c27f2729fc298322baab397
The prior art on other options in the same document seemed to be
calling out the default in a pre-formatted block after describing the
possible values.
I believe the default value for the option was first changed [1], then
the docs were fixed [2], then the information was unintentionally
dropped from the docs [3].
1. Related-Change: If0e0b818355e4cb1338f7fa72af5e81e24361574
2. Related-Change: Ib6603b4f6ea0b4079f9a4ea46e723ecbb2ea371d
3. Related-Change: Iddd27cb54f1d9f062b9c47ff9ad6a2bef3650d6b
Change-Id: I662403db3b08a351a680587440ad1f15a6f8ee5d
Added an option to make subnetpools to be optional
as it ignores the public network specified in
FIXED_RANGE.
DocImpact
Change-Id: Ic89ceca76afda67da5545111972c3348011f294f
Closes-Bug: #1628267
Fix the comment to actually be a comment. Regenerate page.
Although we've got a pretty cool system for generating this, I wonder
if anyone actually looks at it? Maybe it's just helpful as a form of
SEO.
Change-Id: I15aaa983716f9ee897293c2954ca7ae561951372
Removing the explicit enablment of Neutron services, as with [1] they are configured as defaults in stackrc.
[1] https://review.openstack.org/#/c/350750/
Change-Id: Ic8910cd28fe37842f7d824e68bd2ea705e7e52de
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
It turns out we never really had a document on how to work with
devstack in the devstack docs. At one point this was just cultural
knowledge passed down, but with the size of our community, we can't
rely on that any more.
Change-Id: I28f896ea507ccbba5164ebfc5415d22207f52e98
The devstack docs have gotten a bit meandering so even the quick start
guide doesn't get you to a working setup without referencing other
pages. This attempts to pull this back in a bit.
Change-Id: I608331cbdae9cbe4f3e8bd3814415af0390a54d0
MacVTap mechanism driver and agent have been added during
Mitaka [1][2]. Now adding the related doc to run a
multinode devstack with MacVTap compute nodes.
[1] https://review.openstack.org/209538
[2] https://review.openstack.org/275306
Depends-On: I0dd4c0d34d5f1c35b397e5e392ce107fb984b0ba
Change-Id: Ie743a207a5faeab2e2a7274fda503699f3072e98
The local.conf docs talk about phases which don't exist for config
file processing, which makes it more confusing then it needs to be.
Change-Id: If7f9255eab0535c3d57a2fd5f1bc18ba4d0801aa
Wrong container name in devstack "All-In-One Single LXC Container" manual.
Link: http://docs.openstack.org/developer/devstack/guides/lxc.html
After creating "devstack" container with below command
sudo lxc-create -n devstack -t ubuntu -f devstack-lxc.conf -- --packages=bsdmainutils,git
The name should be 'devstack' instead of 'p2' in the below command
ssh ubuntu@$(sudo lxc-info -n p2 | awk '/IP/ { print $2 }')).
Change-Id: I7a84b97b03b2dd4338f1d946b7eafb8ec6e3767d
Closes-bug: #1582248
For client debugging that invokes multiple libs it can be useful
to have all libs directly in git and not listing all of them
in LIBS_FROM_GIT.
TrivialFix
Change-Id: Ie631cc4045231ebbe8177d2d113e47e4bf83f61c
This patch replaces Q_L3_ENABLED with is_service_enabled q-l3.
Both of them idicates wherever Neutron L3 agent is enabled or not.
Change-Id: I33f0f5a6174d1d170bc2ac1c2e3a096d88d17cc1
