Assumes devstack was configured with SERVICE_IP_VERSION in
local.conf
SERVICE_IP_VERSION is stored in .stackenv and checked in
openrc. If SERVICE_IP_VERSION is set to 6, openrc will use
IPv6.
NOTE: At first, I added a '-6' option to the openrc call
which would set the HOSTS accordingly. I then simplified
the code by saving SERVICE_IP_VERSION to the .stackenv file
which is sourced by openrc. After that, I simplified the
code even more by removing an extra, unnecessary, variable.
Change-Id: I5d46d5438d3e56fea788720ca17f0010caef3df1
By default, most Openstack services are bound to 0.0.0.0
and service endpoints are registered as IPv4 addresses.
With this change we introduce two new variables to control
this behavior:
SERVICE_IP_VERSION - can either be "4" or "6".
When set to "4" (default if not set) devstack will operate
as today - most services will open listen sockets on 0.0.0.0
and service endpoints will be registered using HOST_IP as the
address.
When set to "6" devstack services will open listen sockets on ::
and service endpoints will be registered using HOST_IPV6 as the
address.
There is no support for "4+6", more work is required for that.
HOST_IPV6 - if SERVICE_IP_VERSION=6 this must be an IPv6
address configured on the system.
Some existing services, like the Openvswitch agent, will continue
to use IPv4 addresses for things like tunnel endpoints. This is
a current restriction in the code and can be updated at a later
time. This change is just a first step to supporting IPv6-only
control and data planes in devstack.
This change is also partly based on two previous patches,
https://review.openstack.org/#/c/140519/ and
https://review.openstack.org/#/c/176898/
Change-Id: I5c0b775490ce54ab104fd5e89b20fb700212ae74
Co-Authored-By: Sean Collins <sean@coreitpro.com>
Co-Authored-By: Baodong Li <baoli@cisco.com>
Co-Authored-By: Sridhar Gaddam <sridhar.gaddam@enovance.com>
Co-Authored-By: Adam Kacmarsky <adam.kacmarsky@hp.com>
Co-Authored-By: Jeremy Alvis <jeremy.alvis@hp.com>
stackrc needs to do all of the initialization for situations (Grenade,
unstack.sh, etc) that do not run stack.sh
Change-Id: Ib8c7b923dde817b37f852515dd049fcf970b999a
Constraints files allow a global view of dependencies for devstack
without the side effect that requirements files have of installing
everything everytime. This is part of the cross project
requirements-management spec.
Change-Id: If089d30146629e6cf817edd634e5c2b80f1366dd
This allows setting the new option in Tempest for toggling whether
or not the Cinder encrypted volume tests should run.
Depends-On: I48eba7c645cc1c979fd766ae9c05efb00957f787
Related-Bug: #1463525
Change-Id: I9e12f8dc9e3e6b68dc031351cb081ee2bc6e6cbb
Review https://review.openstack.org/#/c/192154/ removed support for RPC backends
other than RabbitMQ, but we should still document how to disable rabbit.
Change-Id: I1fd64b5f02573c58d7b0d1005c39a22c459a09a5
Once the Sahara related code moved to Sahara repo and used, we can
remove Sahara specific code from Devstack.
Partial-Implements: bp sahara-devstack-intree
Change-Id: I34412b5cb2e86944b8555b8fd04b43556eb2bbe6
Depends-on: I2e00b2ebc59dd3be6a0539dea2985f2e801a1bd7
Depends-on: I07c3fede473030e8a110cbf5a08309f890905abf
Before the fix, requirements soft-update was used for projects that are
in the file.
Change-Id: I095d42521f54b45a6b13837e2f8375fa04532faa
Closes-Bug: #1469067
The gate/updown.sh calls the unstack.sh with
-ex option. Normally we do not use -e with unstack.sh.
The unstack.sh can fail if the service already stopped,
and it also can have flaky failures on the gate.
For example the stop_swift function tries to kill swift in two
different ways, and if the first one succeeds before the 2th attempt
the pkill fails the whole unstack.sh.
This change accepts kill failure.
Normally the kill can fail if the process does not exits,
or when you do not have permission to the kill operation.
Since the permission issue is very unlikely in our case,
this change does not tries to distinguish the two operation.
The behavior of the unstack.sh wen you are not using -ex should
not be changed by this change.
Change-Id: I64bf3cbe1b60c96f5b271dcfb620c3d4b50de26b
Unconditionally running this can lead to confusing failure output from
kill as the pgrep matches nothing when nova-compute isn't yet running.
Change-Id: I37cb84fe8e0b393f49b8907af16a3e44f82c46a6
Full list for liberty is as follows:
* oslo.service
* oslo.reports
* automaton
* futurist
oslo.cache was already added in the earlier review
Some of the entries are already there, though automaton was
missing in one spot. Made sure all references have all five
libraries.
Change-Id: Iffb720d46058424924469695a3ae1e4f20655f99
To avoid sourcing this twice and getting globals mixed up,
particularly when using multiple plugins, add a "header guard" that
ensures we only source it once.
In general I don't think functions/functions-common have been written
or considered to be idempotent. I don't think going down that path is
going to be a long-term solution as it's easy to break.
Change-Id: Idca49eb996d2b7ff3779ec27ed672a2da7852590
Closes-Bug: #1469178
Move the failure trap after the functions it uses, so that
"delete_all" is defined when it is triggered.
Change-Id: Icb2465d0f834b8cb2d46dca3c7df4ae06e49d9b5
In documentation like this (which is a huge boon) we should strive to be
as explicit and helpful as possible, so this change tries to be more
clear about what a project.yaml is and where one might go to create it
or change it.
Change-Id: Ia66a361fc7d79e511afa3ad903fffb122b86998b
When using IDENTITY_API_VERSION=3, the clouds.yaml must also set
auth/user_domain_id and project_domain_id.
Change-Id: If028f2935ea729276f40039a4003c07c08e91672
There is properly working is_cinder_enabled now, and this check
actualy matches ironic-inspector, breaking its devstack plugin.
Change-Id: I659ec9b9b2b49690fd075f9766ae8cbf19e81848
Closes-Bug: #1469160
Change I79a8d8ac7ad2fbd7d2fce696821d130218e43e03 removed the install
of python-libguestfs, which was actually hiding a dependency issue on
Centos. The "kvm" package is ultimately missing some bios files from
"seabios-bin" -- however with python-libguestfs installed this was
coming in via a dependency chain that pulled in qemu-kvm, which has
the dependency.
qemu-kvm is not strictly required as all the functionality is within
qemu-system-x86. But while we get [1] sorted out this restores the
job functionality.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1235890
Change-Id: I3379bc497978befac48c5af0f1035b96d030b7eb
Prior to this patch, the logic for configuring the interface used for
the L3 agent was OVS specific. This patch introduces code to correctly
identify the brq device that is used for the L3 agent when using the
Linux Bridge mechanism driver.
Change-Id: I1a36cad0fb790aaa37417a1176576293e4f2c87f
Co-Authored-By: Jens Rosenboom <j.rosenboom@x-ion.de>
