4d784d23a9
When a virtual environment is created with the "--system-site-packages" option and privsep is installed on the system privsep will only use the system packages and completely ignore the ones in the virtual environment. This results in errors such as the ones we see: - In the Ussuri gate: ModuleNotFoundError: No module named 'os_brick.privileged.rootwrap' - In the Wallaby gate: ModuleNotFoundError: No module named 'os_brick.privileged.nvmeof' This happens because os-brick and cinder are starting privsep using the "privsep-helper" mechanism, and privsep was not installed in the virtual env because it was already present system wide, so the "privsep-helper" that is executed is the one from "/usr/local/bin/privsep-helper". This python script "privsep-helper" ignores the virtual environment and forces usage of the system's python, for example in a Wallaby installation this could be "#!/usr/bin/python3.6". Since it ignores the virtual environment it won't use its packages and anything that's not present on system wide will not be found, and if found it may be executing different code. This patch fixes this issue by replacing the helper used to start privsep with our own command. This command is the same as the one usually installed in /usr/local/bin but using /usr/bin/env to select the python to use. This new script has been included as data in the cinderlib namespace instead of making it install as a system script (like the original privsep command) because we don't want to polute the system wide binaries directory just for a corner case. We also need to preserve user site-packages for the running Python when calling root from the virtual environment, since the packages installed on the virtual environment with "--system-site-packages" would have taken those into consideration during the installation and not the ones present on the root user. To help debug issues at the gate all functional tests are now running with debug logs. Change-Id: I0278b42785d14f92a521e6deff872dcba6505270 Related-Bug: #1958159 Closes-Bug: #1979534
Cinder Library
Introduction
The Cinder Library, also known as cinderlib, is a Python library that leverages the Cinder project to provide an object oriented abstraction around Cinder's storage drivers to allow their usage directly without running any of the Cinder services or surrounding services, such as KeyStone, MySQL or RabbitMQ.
- Free software: Apache Software License 2.0
- Documentation: https://docs.openstack.org/cinderlib/latest/
The library is intended for developers who only need the basic CRUD functionality of the drivers and don't care for all the additional features Cinder provides such as quotas, replication, multi-tenancy, migrations, retyping, scheduling, backups, authorization, authentication, REST API, etc.
The library was originally created as an external project, so it didn't have the broad range of backend testing Cinder does, and only a limited number of drivers were validated at the time. Drivers should work out of the box, and we'll keep a list of drivers that have added the cinderlib functional tests to the driver gates confirming they work and ensuring they will keep working.
Features
- Use a Cinder driver without running a DBMS, Message broker, or Cinder service.
- Using multiple simultaneous drivers on the same application.
- Basic operations support:
- Create volume
- Delete volume
- Extend volume
- Clone volume
- Create snapshot
- Delete snapshot
- Create volume from snapshot
- Connect volume
- Disconnect volume
- Local attach
- Local detach
- Validate connector
- Extra Specs for specific backend functionality.
- Backend QoS
- Multi-pool support
- Metadata persistence plugins:
- Stateless: Caller stores JSON serialization.
- Database: Metadata is stored in a database: MySQL, PostgreSQL, SQLite...
- Custom plugin: Caller provides module to store Metadata and cinderlib calls it when necessary.
Demo
