Ia0957b47187c3dcadd46154b17022c4213781112 proposes to have bashate
find instances of setting a local value. The issue is that "local"
always returns 0, thus hiding any failure in the commands running to
set the variable.
This is an automated replacement of such instances
Depends-On: I676c805e8f0401f75cc5367eee83b3d880cdef81
Change-Id: I9c8912a8fd596535589b207d7fc553b9d951d3fe
The python-keystoneclient requires a trailing /v<IDENTITY_API_VERSION> to
successfully authenticate, otherwise it fails with a 404 error due to a not
found resource.
This error showed up only when generating Swift tempurls, because the error was
raised when using python-swiftclient.
This change fixes this for python-swiftclient within devstack.
Change-Id: Ibe222d65162898db69acba076b5fe1cb3621fbc3
Closes-Bug: 1492216
The previous approach assumed that devstack in tree service support
would always be a super set of tempest. That's not necessarily
true. Instead when configuring tempest we should look at all the
possible services that tempest could know about, which will let us
disable services we don't have support for.
Change-Id: I9c24705e494689f09a885eb0a640efd50db33fcf
Swift3 should be in the same region as all other cloud.
By default it has regaion name 'US'. It's ok for requests
that signed by version 1 of signature because they haven't
region information in request.
But S3 signature of version 4 protocol sends region name to server
and swift3 plugin checks that input region equals to internal.
And because all cloud lives with 'RegionOne' then swift3 fails
request because it has 'US' region name by default.
Change-Id: Icd817183b1a040110372a8ae5d73fd2f0ec5559c
Related-Bug: #1411078
The openstack role list command doesn't include any identity API version
information and so will fail when running purely with v3. We could add
this information to the command however we already have a function that
does what swift requires so we should use it.
Change-Id: I5d5417eaed432760bfb97cf35bd76a0919c6004d
Currently, the Swift proxy, object, account, and container servers bind
to IPv4 address 0.0.0.0 by default. In the case of a user setting
SERVICE_IP_VERSION=6 in their local.conf file, these Swift servers still
listen on 0.0.0.0 instead of ::, which causes a ./stack.sh run to fail.
This change explicitly sets the bind_ip variable in the Swift server
config files so that the servers bind to either 0.0.0.0 (when
SERVICE_IP_VERSION != 6) or :: (when SERVICE_IP_VERSION == 6).
This patch is related to the following patch for devstack IPv6 support:
https://review.openstack.org/#/c/192329
Change-Id: Ie268c6daf5374e67ef8710a731c3af50ffdb821e
Always use the keystone V3 API when creating services and endpoints. The syntax
here is slightly different but we maintain the function interface.
Change-Id: Ib3a375918a45fd6e37d873a1a5c0c4b26bdbb5d8
Implements: bp keystonev3
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>
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
This includes requiring a domain when creating a user. This will allow us to
control where users are created in a later patch.
Adding the token to the user creation call is required because of a bad
interaction between OpenStackClient, os-client-config and keystoneclient
when dealing with v2 authentication but v3 API calls. It will be cleaned
up when we switch to v3 credentials.
Change-Id: I6ef50fd384d423bc0f13ee1016a8bdbb0650ecd9
Implements: bp keystonev3
Always use the keystone v3 API for project creation. Make domain a
required argument. Whilst we could simply default this value within the
function I think it's better to make this explicit as these are things
deployers and services need to consider.
In future we will want to figure out how we want devstack to organize domains
however I don't believe that it belongs in this patch.
Change-Id: Ib9587193c5c8419dc4b5a608246709baaddd2a52
Implements: bp keystonev3
Recently, keystoneclient.middleware has been moved from keystoneclient to
keystonemiddleware. The latter should be used.
Change-Id: Ib9489a21b988b32fc17399c08eeb60862efae034
Closes-Bug: #1452315
If SWIFT_DATA_DIR is set on local.conf we need to make sure to create
the directory with proper permissions
Change-Id: If29fa53f01b4c0c8a881ec3734383ecffac334ce
Closes-Bug: 1302893
Minimum Cinder volume size is 1GB so if Swift backend for Glance is only
1GB we can not upload volume to image.
Change-Id: Ifd4cb42bf96367ff3ada0c065fa258fa5ba635d9
This eliminated a number of sudo calls by doing the copy/chown/chmod in
a single step and sets a common pattern.
Change-Id: I9c8f48854d5bc443cc187df0948c28b82c4d2838
swift middleware contained in ceilometer is now deprecated. the
middleware is available in ceilometermiddleware.
Change-Id: I6e41986245f4d95a9385dc7829479ed1199f10ac
The keystonemiddleware 1.5.0 released 2015-03-11 supports configuring
auth plugins from the paste config file. This means that swift can now
use authentication plugins for auth_token middleware.
Change-Id: Icb9f008a57b6f75e0506cbecd0a1e0f28b7dadda
The keystone admin token supposed to be used only
for setting up keystone and it should not be used
in any other service config.
Change-Id: Iaa9be1878e89a6bc3a84a0c57fc6f5cecc371d2f
is_keystone_enabled() was calling is_service_enabled(), which is what called
is_keystone_enabled() in the first place. Make it work as designed and
also change calls to use the full service name. Note that this is all
still comptible with the prior usage of 'is_service_enabled key'.
Change-Id: I9c28377ecf074b7996461d2a4ca12d88dfc4d47e
This breaks Ironic's use of temp URLs, which the key for the service
account is configured via the Swift user.
Change-Id: I69f6f6eef4ad573f406d64d579a9811c70ac5d28
Closes-Bug: #1421006
get_or_add_user_role is specific to adding a role on a project.
Rename it to get_or_add_user_project_role to allow room for adding a
domain specific role function.
Change-Id: I999308098d22be9800578ae67144a3b687fbc3be
Most of the services create the service user with the admin permission.
This is unnecessary for token validation and they should be restricted
to only having the service role.
Change-Id: Id7a9366d2c6a36139240f64371002362dc2d8d3b
The code for creating service users is almost exactly the same. Abstract
this into a function that can be reused and standardized.
Change-Id: I3a4edbff0a928da7ef9b0097a5a8d508fdfab7ff
Swift doesn't use olso.config and so the method of configuring swift via the
[keystone_authtoken] config options will not work. Go back to configuring swift
manually.
This will need to be fixed in either keystonemiddleware or swift as configuring
via plugin is the path to v3 authentication, service domains and new forms of
service user authentication.
Closes-Bug: #1415795
Change-Id: Ibe27116a11756072d5a300a6d3691c5f8c32317e
The default project means that a user gains token scoping information
for a project if they don't specify another. This is something we want
to discourage for user creation. User's should specify there own
authentication scope when they authenticate.
Change-Id: I42c3060d59edfcd44d04cd166bad500419dd99bc
This makes a bunch of variable cleanups that will let -o nounset
function, for the time being we hide nounset behind another setting
variable so that it's not on by default.
Because this is bash, and things are only executed on demand, this
probably only works in the config it was run in. Expect cleaning up
all the paths to be something that takes quite a while.
This also includes a new set of unit tests around the trueorfalse
function, because my change in how it worked, didn't. Tests are good
m'kay.
Change-Id: I71a896623ea9e1f042a73dc0678ce85acf0dc87d
The reseller_prefix option cannot be added to the
swift-proxy-server.conf-sample file because it
inadvertently gets set to "TEMPAUTH" and Tempest
tests fail.
Change-Id: Ib08d6fa1926531b8966151258eae6771c99c41ca
Closes-Bug: 1404226
With gerrit 2.8, and the new change screen, this will trigger syntax
highlighting in gerrit. Thus making reviewing code a lot nicer.
Change-Id: Id238748417ffab53e02d59413dba66f61e724383
We're using all the magic variables based on python-fooclient, however
all the inline code was using fooclient for variables. So we had a
mismatch, which was kindly pointed out by some of the 3rd party ci
testers.
Change-Id: I27a56222c7e8e610fba8bf97672d2a42f5cf14ca
expand the devstack support for libraries from released versions to
support python-* clients and tempest_lib.
Depends-On: I81b0d228e7769758c61e5b0323ecfce8c8886d39
Change-Id: I26fac0ccf8fd4818e24618d56bf04b32306f88f6
