manila's tempest plugin is branchless and can at
any time add tests for API microversions incompatible
with stable branches.
We used to configure test API versions via the post test
hook when relying on devstack-gate. However, API version
config makes sense whenever we use devstack and have
tempest enabled. This will help us simplify default
job configuration in the manila-tempest-plugin repository.
Since the API version won't change on a stable branch,
hard-coding the versions (as other micro-versioned services
do in their devstack) doesn't pose any risk of failing
reality.
Change-Id: Ia671fa74c0ee338199bd92a1613882328d24c9e2
Related-Bug: #1928879
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
We used a workaround to solve the lack of legacy credentials
in our devstack plugin script by sourcing credentials early [1].
This workaround breaks when using the devstack-system-admin
persona from the /etc/openstack/clouds.yaml that devstack
sets up, because we'd be sourcing project credentials that aren't
popped off in time [2]. Cloud profiles work with OSC, we could
switch to that in the devstack plugin rather than rely on legacy
credential helpers from devstack. The only remaining piece is the
group type setup [3] which is expected to be complete soon.
[1] https://review.opendev.org/c/openstack/manila/+/818617
[2] https://review.opendev.org/c/openstack/devstack/+/817074
[3] https://review.opendev.org/c/openstack/python-manilaclient/+/805064
Change-Id: Icc15f427cc02054021fa23626ea14e6cd37b18fb
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
A change that stops loading credentials from userrc_early file [1]
was merged. Creating resources using the python-manilaclient
requires some parameters that were set while loading such file.
This change starts loading the credentials during the manila setup,
so the client can normally create the resources.
Change-Id: Id872f6e62b6464544a4edfbc2d3e7c954042f6e2
Use install_package instead of using a specific package manager
while installing docker on fedora systems. With DNF also a
possibility, the better option is to do not take a stand in chosing
which package manager will be used to install packages.
We have a install_package function that will use the appropriate
package manager to install the programs we need to install.
Change-Id: I0524554dae2d6970191ba3afa583480c391b5c3c
manila.scheduler.filter_scheduler.*Scheduler was deprecated long ago[1]
in favor of new manila.scheduler.drivers.filter.*Scheduler.
[1] 3ffb4979f328259793079a5ece6f3b79e23f5187
Change-Id: I40349cbe106f688a67043a73f8563f87f069831b
This method of installing manila-tempest-plugin
was deprecated several releases ago, but compatibility
was maintained for third party CI jobs. Since sufficient
time has passed allowing third party CI to adopt,
lets drop this from the devstack plugin
Change-Id: I59ffe6ebe4b2e80be1e6ae97872cf4db6527da62
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
A few releases ago, service types were standardized
across OpenStack [1] and manila's service type was
recommended as "shared-file-system" [2]. Tools were
meant to look at the service-types-authority [3]
and os-service-types repository [4] to find a list
of standard service type names for various first
party OpenStack services.
The openstacksdk currently relies on the service
type to be "shared-file-system" [5], so let's set
one up in devstack, to aid contributors working on
openstacksdk.
It is desirable to have all clients to initially
look for the standard service type name in the
cloud's service catalog, and fall back to the
legacy name ("sharev2") in environments that
call the v2 API that.
[1] https://specs.openstack.org/openstack/service-types-authority/
[2] https://service-types.openstack.org/service-types.json
[3] https://opendev.org/openstack/service-types-authority
[4] https://opendev.org/openstack/os-service-types
[5] f4dd6fe5fd/openstack/_services_mixin.py (L71-L72)
Change-Id: I6a1ada102a40f3e83fe8e5287856d01dd137ea95
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs. We can stop
devstack from setting up an endpoint with
project_id in it.
Create a "sharev2_legacy" endpoint that
contains the project_id for testing the
compatibility with the older style of URLs.
Change-Id: I25aeb1b6dd1a4150c6e542e29b7d43e18d9ad94c
Implements: bp remove-project-id-from-urls
Depends-On: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
MANILA_MULTI_BACKEND has been deprecated for five years now, we should remove
it from our code base.
This variable was removed from the settings scripts along with:
MANILA_BACKEND1_CONFIG_GROUP_NAME and MANILA_SHARE_BACKEND1_NAME;
MANILA_BACKEND2_CONFIG_GROUP_NAME and MANILA_SHARE_BACKEND2_NAME.
Because they work in the same context.
Instead of them, the already implemented and in use,
MANILA_ENABLED_BACKENDS variable was placed to garantee the successful
back-end setup. The same replacement was made in the contribution
samples scripts.
Apart from this, we avoid configuring generic1 and generic2 if
another backend/s are selected.
Closes-Bug: #1898791
Closes-Bug: #1878477
Change-Id: I67036a65da9255694a00a9c8d56cfdefbdf23c05
We were using an env var with the IPv4 gateway config
that is not always present. This was causing devstack to fail
in developer environment. Use the local variable instead.
Closes-Bug: #1910760
Change-Id: Iede8a9e59b96d0f21c117ab1464a0a9e3477c24b
When you run unstack.sh from devstack, other devstack
services are stopped and disabled to provide a clean environment
for a restack, but manila services are left running.
This doesn't matter for CI where a new VM is stood up for each
devstack but it's inconvenient for local devstack and if you
restack without restarting the services manually the results you
see may not actually match the environment you intended.
Change-Id: I6761619042e4bc36ec2f1cab4be33cb1b39d00d7
This patch adds support for migration of share servers. This
migration is performed using a two-phase approach. Administrators
are now able to request the migration of a share server within and
across backends, with the possibility of chooosing a different share
network for the destination share server.
- A new field called `task_state` was added to the share server
model in order to help the administrator to track the share server
migration steps. A new field called `source_share_server_id` was
added to link destination and source share servers.
- A new periodic task was added to track migration of share servers
and its resources.
- Two new states were added: `server_migrating` and
`server_migrating_to` to represent that share migration is in
progress.
- When performing the server migration, manila will not go to the
scheduler, instead it will provide a request spec to drivers
during migration check driver call. It'll be up to the driver
validate if there is free space to handle the share server.
- A new API called `share-server-migration-check' was added to
check the feasibility of a migration, before actually triggering
the start operation.
APIImpact
DocImpact
Partially Implements: bp share-server-migration
Co-Authored-By: Andre Beltrami <debeltrami@gmail.com>
Co-Authored-By: Carlos Eduardo <ces.eduardo98@gmail.com>
Co-Authored-By: Felipe Rodrigues <felipefuty01@gmail.com>
Change-Id: Ic0751027d2c3f1ef7ab0f7836baff3070a230cfd
Signed-off-by: Douglas Viroel <viroel@gmail.com>
The existing "manila-grenade" job relies on
devstack-gate, a deprecated project. The Grenade
project now has a native zuulv3 style job that
we can inherit and run manila's upgrade tests.
Manila's grenade tests are only going to run
API tests, and hence this grenade job doesn't
have to enable nova, cinder, glance, neutron
and swift. However, bug #1887835 prevents
us from disabling nova at the moment,
and nova requires glance, placement and neutron
to be deployed, so we'll be enabling these
services too until that bug is addressed.
Depends-On: Id5a9467247df1d8f0ec6dee3fae842ba673c34ed
Depends-On: Ieaf37ec10db9a8bdce6bb195b76335fea9b2b52f
Change-Id: I1636c612ac2475f7a00c0888ef62daa6c516eef2
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Switch to using the LVM driver in the grenade
job that allows us to add a minor data
path test to prove that upgrading manila
has no impact on data path connectivity
to resources created by manila.
Change-Id: I8588e8f988d85dc64e19e7a44a25c3dd0b776892
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Needed for zuulv3 jobs that use two
devstack plugins that need to be invoked
in a pre-defined order [1]
[1] https://docs.openstack.org/devstack/latest/plugins.html#plugin-interface
Change-Id: I44117debfc5b7cdef6acb706786963ec81f59db7
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
When the image count is over 25, there might not get
manila-service-image, because current manila shares
creation is using novaclient to get image info, but
novaclient can only get 25 images due to pagination
of glance server, So this change is to switch to use
glanceclient instead of novaclient to get image info,
because glanceclient can iter all image info, while
novaclient is rarely maintained with stuff of image
API.
Change-Id: Id1715d0b9cb3a4aeedeb23d9b1d9924a78d18dc6
Closes-Bug: #1741425
After fixing the uwsgi installation from source that was broken[1][2],
Manila jobs started to fail since no uwsgi wasn't found in the
expected path. This fix now uses 'which' command to search for
uwsgi pathnames in the system.
[1] https://bugs.launchpad.net/devstack/+bug/1883468
[2] https://review.opendev.org/#/c/577955/
Related-Bug: #1883468
Closes-Bug: #1883715
Change-Id: I8d8b2fe07d86899c694cb73a81087d25311d30a5
If the cephfs protocol is enabled, clients
need to access the ceph daemons.
We also don't need to enable access to NFS
ports when not using NFS.
Change-Id: I077d12785f94c940716f0e479d43dbb29ddc3c3c
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
When running IPv6 tests, we disable the creation of
the public network in devstack, and handle it in the
devstack plugin. So, we'll need to configure it
in tempest in the plugin.
Change-Id: Icf5f26397e16d7fbfae77aa246ac5e35581f441e
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Devstack no longer installs this package after [1]. The driver
needs to replace the use of brctl to completely remove this
package from our test environments.
[1] https://review.opendev.org/724443/
Partial-Bug: #1876820
Change-Id: Id6094827341bf6ef8856cd4e7af11b36e9afb560
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
We currently use a legacy devstack-gate script
to create the bgp speaker, and peer required
to communicate to and from the tenant private
IPv6 networks.
Move this logic to the devstack plugin so that
we can invoke it automatically with the existing
devstack variable MANILA_SETUP_IPV6.
Change-Id: Iea90e3f04ae05e5783c3163bbf2d2dabd128c7b5
A fix was committed [1] to the python-openstackclient
project to handle VMs with multiple ports. We can
drop the workaround of setting a floating IP to the
VM's port.
[1] 013c9a4f3a
Change-Id: I67c38b4e6695c05a8272a86448ed248b492a279d
Closes-Bug: #1747721
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
To set up some first party backends such as
ZFSOnLinux, CephFS via NFS gateway, Container
(where the NAS server is containerized) and LVM,
manila's devstack plugin creates a NAS server
on the devstack host.
On test machines, access to this NAS server is
firewalled from networks outside of the host's
internal network namespace (including from private
project networks that are in different network
namespaces, on the same devstack host).
We currently use a legacy devstack-gate script
to disable firewall on NFS ports; however,
anyone that installs devstack with LVM, Container,
ZFSOnLinux, CephFS-NFS drivers will need these
firewall ports to be opened to be able to mount
shares exported off their devstack host machines.
Move these firewall commands to the devstack plugin.
These commands can be invoked by setting the localrc
variable MANILA_ALLOW_NAS_SERVER_PORTS_ON_HOST to True.
The value of this variable is False by default,
to preserve existing behavior.
Change-Id: Ic9cad47662f1edf2e5c710dbe64d580bc5f01d44
Grenade jobs need to test Ussuri-->Victoria (dev)
upgrades in the master branch.
Change-Id: I95d1efb35f1c3c311071448117406bc275281e43
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This job fails because it's expecting network subnet
details to be in a format that was revised in API version
2.51.
This change can be backported to stable/ussuri
and only impacts the CI.
Change-Id: I3731e6acffccd2ecb398f3b5cf81a5f294c51f45
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
The manila service image was recently rebuilt and is
now bigger than 2 Gibibytes so increase it to 3, which
should last us for a while.
Closes-bug: #1870412
Change-Id: Ia03e48a3f0ff352b94a0224f76f278ef45acad93
This patch enables the use scheduler creating share from
snapshot flag in order to run properly the manila tempest tests.
Partially-implements: bp create-share-from-snapshot-in-another-pool-or-backend
Change-Id: I15311089c45be1574857d46caa073e89424e716d
Today we either expose the CephFS back end via the CephFS native
protocol, in which case kernel NFS and Samba are not needed, or
by NFS-Ganesha, in which case Samba is not needed and kernel NFS
is incompatible (we just turn it off again later).
In the future someone could develop support for exposing CephFS via
Samba so we'd add specific checks for that then and install Samba.
Change-Id: Id65ce2536a3deb32a04a70bd0c49081297741965
It was deprecated in the Queens release, in
favor of ``data_node_access_ips``.
Change-Id: I01f24c2e0d66e1da4c30c579c02afc8f3930c8f8
Related-Bug: #1745436
In Devstack, even though horizon and manila plugins are enabled, if the
manila ui plugin is not explicitly enabled it won't show up.
This change adds config instructions in the readme and in the manila
contributor docs to enable Manila UI when deploying with Devstack.
Change-Id: I421db5b8ed56fecc90ac7e6d32078d443a3eaa2e
configure_auth_token_middleware was replaced by
configure_keystone_authtoken_middleware in
Id0dec1ba72467cce5cacfcfdb2bc0af2bd3a3610. Manila's
DevStack plugin no longer needs to create a cache
directory to use as the signing_dir for keystone
authtoken.
Change-Id: I18fa04e6c3a832e17ade3f84d8b43b15686f06fe
manila-tempest-plugin can be installed with its
devstack plugin; Installing it via manila's plugin
is unnecessary. So, deprecate its installation
in the DevStack plugin.
Change-Id: I21c08069ff82b3bfb52ef7ac960183ddc866c2ee
Restoring the default IPv6 route is not needed in CI and
fails when there are multiple defaults, but it is useful
in local devstacks where multiple default routes are not
typical.
Add a variable in settings and use it to make this behavior
conditional and set it to False for the lvm job.
Closes-bug: #1836788
Change-Id: Id73de8100509ec5935641f5f35f93f482d108bcd
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I4df9f22a60ef50677867eaf4baf9e7e55a951dda
Switch manila to use devstack common functions
for deploying a wsgi app under uwsgi and apache.
This change aims to fulfill the community requirement
for all projects on OpenStack to switch devstack jobs
to deploy control-plane API services under uwsgi with
Apache acting as a front end proxy.
More details in https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
We used to deploy with mod_wsgi, but mod_wsgi has many
issues when being used in devstack for development or testing.
Now we leave mod_wsgi as optional and we default to uwsgi.
Implements: bp wsgi-web-servers-support
Depends-On: https://review.openstack.org/#/c/643188/
Change-Id: I12d4c864f2ceb0f3555e32d2dc893e00dbef0d96
Enabling tls-proxy allows devstack to
set up a tls proxy server that front-ends
interactions with the manila-api and
terminates tls connections.
Also enable tls-proxy in dummy and lvm
jobs. The dummy driver job is configured
to run the in-built wsgi server, the lvm
job is configured to use mod-wsgi.
Closes-Bug: #1816836
Change-Id: I48b0ccc082604d78242ba61bee94a45efeb2467b
We are getting:
403 errors 'Only volume-backed servers are allowed for flavors
with zero disk' on scenario tests.
Appears to be due to this change [1] which just merged to
nova master branch. Ubuntu bionic server doc says the root disk
needs 1.5 GB so we are setting the flavor definition to require
2GB.
[1] c8e65a5eb1
Closes-bug: #1816050
Change-Id: Iba0a15b78bf75a04c1ac0e64e70634772b2dca5c
