Give instructions to add permissions for stack user without touching
main config.
Closes-Bug: #1680459
Closes-Bug: #1681418
Change-Id: Idd27e684e63c616466de28c07551729a1e091bdd
Since Feb 25th devstack supported operating systems changed
due to Nova increasing its minimum required libvirt version.
Further details see: I6617283afd798af37e64913b7865cea3c8a62aba
This patch is to update versions on devstack documentation.
Change-Id: I12bb59b0903a728376ee9422213c2903b9138249
single-machine.rst and index.rst
Before this, one had to create /opt/stack
manually and chown it to the stack user.
Now it is created when the user is created.
This is the same way the multi-node guide
handles it. A stack group is created too.
Change-Id: I5363d81c8fb38796f565cc6ebf6ab2dee2673989
Closes-Bug: #1673787
Closes-Bug: #1671409
It's 2017, some of our newest OpenStack developers/users may not
even know what stable/kilo is/was.
Change-Id: I00f39cc80af7e1632293bf057d95040b6bfa48e0
Adding sudo to the example commands in the quick start section.
Also adding '-' as su argument in order to use
the stack user's env (home).
Change-Id: I23ab38104d05c3f4c8d48b55e66cf19dc4e4f90d
The order of the steps were a bit confusing for the first timers
in the devstack document. So, changed the order of installation
steps to make it clear.
Change-Id: Ifaa051887dab95719b9ca5d1b2fbe2f5f549d269
Closes-Bug: #1627939
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
We should be using $VOLUME_GROUP_NAME instead since Icehouse.
$VOLUME_GROUP_NAME has been introduced in
I93b8ef32832269d730c76a6dc24ddb4f20c6d9df and $VOLUME_GROUP is nowadays
only use as a fallback to $VOLUME_GROUP_NAME.
As a code comment in lib/lvm says it we kept the $VOLUME_GROUP around as
"for compatibility with icehouse-generation Grenade". Icehouse is long
gone so now seems a good time to remove any usage of $VOLUME_GROUP.
Change-Id: Id3051b5a196c45266c39fde4f08401aaacf0f6bd
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
