The intent was to make any ipv6 safe addr range bigger than a /64 a /64
when setting the fixed range. Unfortunately the awk only emited the mask
and not the addr. Fix this by sprinkling the address back in.
Fixes-Bug: 1643055
Change-Id: I526d4c748fd404ecb3c77afcbb056aa95090c409
If devstack is deployed in the VM with defined
public IP address (like 192.168.10.6) it is not possible to
access the Horizon from the browser.
This is because DEBUG=True means that ALLOWED_HOSTS, if not set,
is equal to ['localhost', '127.0.0.1', '[::1]'] according
to Django's documentation.
Change-Id: I74ae99569dafa10eee7066713a05fb49183e3fca
Currently devstack assumes that the network used for ssh
validation is the private network. This patch adds a hook that
sets the network used for ssh validation based on whether or not
provider networking is being used. It also moves the function
'is_provider_network' into functions-common as it will now be
used by both tempest and neutron.
Change-Id: I265c9e26c9bfb18b7e201f27d8912b8bec235872
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
When using zypper remove, include the -y option to avoid stack.sh from
hanging waiting for user confirmation. Due to output buffering, the
script could hang before giving the user the prompt to enter Y to
continue, making it unclear why the script was hanging.
Change-Id: I5ea761e5ae0829439953c385f8e7d0546acba886
Closes-Bug: 1642736
Swift port base was changed in Ifd95b99004aead5ddc8ae1a8dd3ccd9c4f2abe91
but we forgot to update the rsyncd.conf. This patch update the rsyncd.conf
file.
Change-Id: Id457c047c672a810c4c0c7721b6beeb01b719879
When using the enable_plugin command and grenade jobs it can be
easy to enable the same plugin twice, as the grenade job has a
registration section and the configuration in project-config can also
enable it due to code-reuse in project-config.
If a plugin is enabled twice it will likely fail, though it won't be
obvious that it was due to the plugin being enabled multiple times.
This change makes it so if it sees the same plugin name is enabled
more than once it will die and an error message outputted.
Change-Id: I9f1d7e58b861b04473b6a57c9ad404203fb7277a
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 removes the logic to add a route pointing to the IPv4
tenant private network range since the router is performing
SNAT. If reaching the IPs via the route worked at all, it was
by accident since this behavior is certainly not guaranteed
by Neutron.
Change-Id: If45e3fc15c050cfbac11b57c1eaf137dd7ed816f
Currently the x509 certificate setup is done after all the
openstack services have been deployed. This is OK because
none of the services require that the x509 certs exist
when they are being deployed. With the integration of TLS
into the nova novnc proxy (and later spice & serial proxy)
service, x509 certs will need to exist before Nova is
deployed.
The CA setup must thus be moved earlier in the devstack
deployment flow, prior to the setup of any services. One
part of the CA setup, however, fixes up the global cert
bundle locations and this can only be done after the
python requests module is install, thus must remain in
its current location.
Change-Id: Idcd264fb73bb88dc2f4280c53c013dfe4364afff
The deprecated AMI image file opts will be removed soon.
See https://review.openstack.org/#/c/338377.
So we can't use the fallback mechanism anymore. This patch is to
specify the correct image parameters for XenServer.
Change-Id: Ic287a3ed1725c42ea29022158bc9720c9a96533f
Previously the usage of neutron debug ports was removed by
5e01c47e4d671166b9396c507a7105a5ac8256dc but there was still call to
teardown_neutron_debug. Recently a change to devstack-gate
1d6cc0771a3399300117f488e9d71e7ea46a4d82 caused that call to be
triggered and breaking the gate-devstack-dsvm-updown job.
This patch deletes the call and comments regarding setup_neutron_debug
and teardown_neutron_debug.
Change-Id: Ifdacb0cec1307db469bd66f551474539184cf2cd
Besides updating to OSC CLI, this patch also fixes an argument name typo
present before in 'nova keypair-add' (--pub_key should be --pub-key).
Specifying $OS_PROJECT_NAME in case user is associated to multiple
projects containing security groups with same name (e.g. 'default').
Change-Id: I776f6edfc4c6c798a39d3260827a18c695f05c87
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
When using neutron network under xenserver, we must enable linux bridge
in Dom0 as neutron will use linux bridge qbr in compute node for
security group. But by default XenServer use openvswitch and disabled
linux bridge. This patch is to remove this restriction.
Change-Id: I0e8124ff2323810fdc46c717a750ce7e8f4aa0c6
The initial start of the neutron OVS agent always prints
a warning:
WARNING stevedore.named [] Could not load
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
There's an alias for that in setup.cfg called
iptables_hybrid that would avoid it.
Change-Id: I3f5bf782f4f27dc123e462e494741a8a941641ec
This commit removes some config values for tempest that no
longer exist in tempest/config.py therefore are no longer needed
in tempest.conf.
Change-Id: I5778973012e57e8d9df9bf864590f8ed7fe05561
Sets the port_security feature flag in tempest.conf
if the port_security extension is enabled, which it's not
by default in neutron but is set by default in devstack.
This adds global variable for setting the port_security
extension in ml2.conf and in tempest.conf so we only have
to set this in one place.
Depends-On: I1efd5c838aa0d73cc6e8864e3041eea25850198d
Change-Id: I6334b200e42edd785f74cfb41520627393039619
Related-Bug: #1624082
this is the first patch in a series to actually make fernet the default
token provider in keystone. the patches for grenade, release notes, and
actually switching the value in keystone all depend on this patch first.
reasons for switching over:
- fernet tokens are the recommended token provider
- the install guide for newton recommends deployers use fernet tokens [0]
- we previously attempted this switch but ran into timing issues [1],
the timing issues have been resolved [2]
[0] http://docs.openstack.org/newton/install-guide-ubuntu/keystone-install.html
[1] 153db269705f37d4144ad3fcf26dc67269755d7d
[2] https://review.openstack.org/#/q/topic:make-fernet-default
Change-Id: I3b819ae8d2924f3bece03902e05d1a8c5e5923f1
The devstack ldap configuration for keystone is still using some
old options that are no longer valid. The write support is
being removed this release. And in previous releases, the ldap
assignment driver support was removed and was not removed here.
Change-Id: I538626b681eaee6a7ac10dfbc29605b73fbe13bf
To avoid it being created multiple times for multinode setup.
Note: This reverts "Enable neutron to work in a multi node setup"
(commit 88f8558d874072536e7660a233f24207a7089651) partly and fixes
the issue differently.
The configuration in question uses the new lib/neutron. (not neutron-legacy)
In that case, calling create_neutron_initial_network from stack.sh directly
is a wrong way, as create_neutron_initial_network is sourced by
neutron-legacy. The new neutron code should not rely on the legacy one.
Closes-Bug: #1613069
Change-Id: I868afeb065d80d8ccd57630b90658e330ab94251
Q_ variables belong to neutron-legacy.
These are True by default in neutron.
Remove them in favor of post-config meta section.
Change-Id: If691a79b09003f85a07c9f33e0379a2b21e48141
Until the policy changes land for Nova, Glance, etc, this
value is not used. Additionally, by having it set, it actually
makes it hard/impossible for the required changes to land in
the other services. Disable/comment out the changes in the
Keystone specific lib file for now, and we will re-enable once
the Services can make use of them.
Change-Id: Ia1de9083c21107dac2f0abb56bda166bdb37a69d
