If the nodepool info file is around, assume we're on a OpenStack CI
node and skip re-installing EPEL & RDO
Change-Id: Ife80af015b26514098e0633f568e3da35b9eea8c
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
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
This commit adds a deprecation warning for lib/neutron-legacy. Right
now lib/neutron isn't quite in a place where we can use it by default
but we're getting close. As soon as it's passing in the gate we plan
to make a switch over and a hard delete of lib/neutron-legacy. To give
any users which have a hard dependency on it (which is not actually
a supported use case) a heads up this adds the deprecation warning
in front of that change.
Change-Id: Idf1faf2e9dd497f9b97abfcc6e796ca72d60d955
The commit message of 2a242519f71e86416e78541826cac2b54fcd04a5 indicated
that neutron-metadata-agent was the correct name for the metadata
proxy, but parts of the code were not consistent.
Change-Id: I52f08266a169aeb9005c0f84296fc814d05b90d4
When creating service users, the assumption is that the service
project lies within the service domain, so create it there.
Change-Id: I4880e789f5eaf340634ceb792397eef12a5a6b51
Closes-Bug: 1580998
This is a follow up patch of [1].
In [1], source has been moved from lib/neutron-legacy to lib/neutron_plugins/services/l3.
However, one necessary function of is_provider_network is lost.
And this cause devstack install fail.
[1]https://review.openstack.org/168438/
Change-Id: I413b3577ec5b11ee0ee01f2368364117962494bb
I goofed when moving it over, and it looks like the calls
to _move_neutron_addresses_route got clobbered.
Changes like a0d1b0151a9d9e169e6342f36a073e8154119924 ended up getting
dropped on the floor, so let's reintroduce them.
Change-Id: I3bbfbc56e2c663c47a03659a1dff96443c13af47
There are a few CI efforts going on related to jobs that use the lvm
image backend for the libvirt driver in Nova. We don't want to waste
time zero'ing out volumes during CI runs, so we need a way to configure
nova to not clear the volumes in these jobs.
This change adds a variable used to set the CONF.libvirt.volume_clear
value in nova.conf. If the variable isn't set, Nova just uses the default.
This will be set to 'none' in the jobs that are going to use LVM.
Co-Authored-By: Matt Riedemann <mriedem@us.ibm.com>
Change-Id: I1e97ba6ab4772a87192ae2689a25050d432358ab
This helps fix an issue where an IPv4 address is moved from an interface
and you lose your SSH session.
Change-Id: Idf37ccbaa6f615fcc714d49c3f0c00c893f56021
Background for this work can be read on the mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094063.html
Usage of the new Neutron is by setting the following in
ENABLED_SERVICES:
* neutron-api
* neutron-l3
* neutron-agent
* neutron-dhcp
* neutron-metadata-agent
For now, the new neutron library supports just the ML2 plugin, with the
Open vSwitch and Linux Bridge agents supported. All other Neutron
plugins should be creating their own DevStack plugin if they wish for
DevStack to support them. Many of them already do.
Other notable changes compared to neutron-legacy:
* Rely on the Neutron defaults, and force Neutron to make
sane defaults instead of all kinds of knobs in DevStack.
* Default to rootwrap daemon support
* Use the security group driver by default
* interface_driver can now use NEUTRON_AGENT (linuxbridge, openvswitch), since
they are entrypoints in neutron's setup.cfg
* Use NEUTRON_AGENT variable to determine which agent to run
Works with NEUTRON_AGENT set to either "linuxbridge" or "openvswitch"
Default is openvswitch for the time being.
* Set ML2 configuration for VXLAN support
* Remove Xen hypervisor stuff - it should be a plugin
* Move L3 crud into separate service file:
There's a lot of L3 configuration that was in the main neutron file, but
a lot of it is self contained and can be moved into its own file.
The new l3 service file will contain all the previous L3 plumbing and
configuration that the OpenStack Gate expects, while also eventually
moving the whole l3 network creation step into a single hook that can be
overridden by plugins.
* Introduce a check for a function "neutron_plugin_create_initial_networks" which
will become the mechanism through which different topologies, and
networking plugins can create and wire the initial networks that are
created during a stack.sh run.
The new lib/neutron is considered experimental, and followup patches
will build upon this one. Existing users of lib/neutron-legacy should
remain unharmed.
Co-Authored-By: Hirofumi Ichihara <ichihara.hirofumi@lab.ntt.co.jp>
Co-Authored-By: Dean Troyer <dtroyer@gmail.com>
Change-Id: I31b6362c6d9992f425f2dedbbeff2568390a93da
This seems to break Ironic gate with n-cpu not starting
any more.
This reverts commit c527ded91bef5d4c56cbdb2402a4d68015364b37.
Change-Id: Idfb01448e8ecf53fbd2e1df61c8f08f3107981ac
Closes-Bug: #1579683
As can be seen in logs of the periodic generation job, our cgit does a
weird thing where sometimes it returns a 404 page with content, and
sometimes a zero response (see [1] for example, the last number is
response size). This appears to be an openstack CI issue; possibly
due to cgit caching or similar (see [2] for manual test). It will
have to be investigated with the host apache logs.
This is resulting in a lot of projects incorrectly being picked up as
having plugins (I7116571d2a2b1fc3a61e5f1ed46ac2cbc244775a). I'm not
sure if this problem is also releated to the original status-code
issues mentioned in the code, but testing shows that cgit is correctly
returning 404's for missing files (you can see in the logs [1]). Thus
switch the logic to examine the return code which avoids this issue.
[1] http://logs.openstack.org/periodic/propose-devstack-plugins-list/e55790c/console.html.gz#_2016-05-04_06_46_51_660
[2] http://paste.openstack.org/show/496434/
Change-Id: I6a06347d91d091441f6f7b70f99aba6d8e9add4b
Currently, the db sync operation does not specify the config dir or
config file.
If there is a config file in the home path, it will use this one,
but not the right one devstack write.
Set config file to these operations.
Change-Id: Id1fbc3d85280c19596f5ebd301c46bcf018fa2f6
Closes-Bug: #1578098
Export the 'short_source' function so that it will be present in the
environment for child shell scripts. Do this because we are passing PS4
to the child shell scripts and it is using 'short_source'
Don't do an 'env_keep' in the sudoers file for PS4, since it is
difficult to also pass along the 'short_source' function.
Change-Id: I9781010d6eb336d02939c7fd47f18bedeae5ccc6
Closes-Bug: #1563443
Devstack installs elasticsearch version 1.4.2 by default.
This version is really out of date and you can't run kibana
4.x against it. We are working towards 2.x support [0],
but in the meantime would like our example to install a more
recent version of ES.
[0] http://lists.openstack.org/pipermail/openstack-dev/2016-April/092583.html
Change-Id: I9ca244f8b817dd9c5f6d7435e347df28282db0a9
the referenced file was removed with the following change
Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
Change-Id: I0e25b1f38e0969037d1c8af367432da56bb12e92
This commit adds a new variable to lib/tempest to provide the plugins
that should be installed into common tox venv that gets created. In
order to make this work the workarounds to handle migrating to a common
tox venv have to be removed otherwise the plugins could be installed in
a venv that isn't used.
Change-Id: I63658b8d8dfa999e0feb79f8f2968f2b32e3ff57
Depends-On: Iab2e6e04b6c5795a4d0c8214564106525b942308
