... because these options are configured by devstack. This allows us to
honor some options which determine whether these accounts should be
used(eg. TEMPEST_HAS_ADMIN)
Also, this fixes the inconsistent default value of admin password (it
defaults to 'secret' in devstack).
Change-Id: I6221168ad400346bf1542ed7715c481295e42e04
We need an admin to setup share and group
types and per recent changes [1], this needs to
be a user with the "admin" role, operating
with "project" scope and not "system" scope.
Also remove a TODO in the code that was completed
with a prior SRBAC patch.
[1] https://review.opendev.org/c/openstack/manila/+/856394
Change-Id: I7bd2bca2bac6b892e7b8a07654d33a56d915e3bb
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
brctl is being deprecated in some Linux distros, so
change container driver to start using iproute2 commands.
Closes-bug: #1877410
Change-Id: If679e79fa3242ee1cd8610b5525deca35b41c87e
MANILA_INSTALL_TEMPEST_PLUGIN_SYSTEMWIDE is an
unused variable since 3b6ea36904.
This variable only makes sense in the stable/wallaby and
older branches and is recommended to be set to False;
the correct way of getting the tempest plugin installed
would be to use the "TEMPEST_PLUGINS" devstack setting.
Change-Id: I2d94d780d879053f0fa739ba61f77f956ec84cd4
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Manila plugin is setting the availability zone of the
backends without checking if it is set. As result, a CI
configuring that field will not be respected.
Fixed by only setting the field in case its value was
not set before. Otherwise, keep as it is.
Change-Id: I546e5f057f3b748417dcbcfe9c3f3ae4a5d51556
... because the policy rules are implemented in code. Also now Manila
uses policy.yaml instead of policy.json.
Change-Id: I4b03ec81a5a72491734ca1c76b50162399d5c370
Ubuntu Jammy was failing to spawn while using the manila flavor.
It was hitting kernel panic and complaining about memory. That
leads us to increase the flavor to be used in the manila service
image.
Depends-On: Id2d35ce592c73f0c731deb17a5d574f502fe64cb
Change-Id: Idd3e6a6fdb8cf13727cd674c76efd89b3aacfc52
RSA key is no longer enabled by default in recent openssl library.
Because of this change, RSA key does not work in recent Fedora and
CentOS Stream 9 unless it is enabled somehow.
This introduces a new MANILA_KEY_FORMAT parameter to devstack plugin
so that a different ssh key format (eg. ecdsa) can be used.
Change-Id: Ibe60da0b06cade641002d5a1650c38aa57c2d131
To build the manila service image with
Ubuntu Jammy Jellyfish (22.04 LTS) we need
a slight bump in the storage allocated.
Change-Id: I1d60834c2045c069de25a1c8979c433d4dd50684
Related-bug: #1870412
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
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] 3ffb4979f3
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
Kiran Pawar